💡 Key Takeaways
- Authentication and Authorization: The Foundation That Everyone Rushes Past
- Request Validation: Where Most Bugs Actually Live
- Response Validation: Trust, But Verify
- State Management and Idempotency: The Subtle Art of Consistency
3년 전, 저는 아무도 "32/13/2021" 형식의 날짜 필드를 보낼 때 발생하는 상황을 테스트하지 않아, 오전 2시에 프로덕션 API가 극적으로 실패하는 모습을 지켜봤습니다. 그 연쇄 반응은 최악의 방식으로 아름다웠습니다: 47,000개의 실패한 거래, 지원 채널에 몰려드는 분노한 고객들, 그리고 제가답을 갖고 있지 않은 CEO. 그날 밤 이후로 API 테스트 접근 방법이 완전히 바뀌었습니다.
💡 주요 내용
- 인증 및 권한 부여: 누구나 서둘러 지나치는 기초
- 요청 유효성 검사: 대부분의 버그가 실제로 존재하는 곳
- 응답 유효성 검사: 신뢰하되 검증하라
- 상태 관리 및 멱등성: 일관성의 미세한 예술
저는 사라 첸이며, 지난 8년 간 QA 자동화 엔지니어로 일해왔고, 그 중 지난 5년은 핀테크 및 헬스케어 플랫폼의 API 테스트에만 집중했습니다. 간단한 CRUD 엔드포인트에서 일일 수백만 달러를 처리하는 복잡한 결제 처리 API까지 모든 것을 테스트했습니다. 제가 배운 것은 대부분의 API 실패가 이국적인 엣지 케이스가 아니라 예측 가능한 문제라는 것입니다. 체계적인 체크리스트로 쉽게 발견할 수 있었습니다.
오늘 제가 공유하는 체크리스트는 제가 테스트하는 모든 엔드포인트에 사용하는 정확한 것입니다. 이벤트가 발생한 지난 1년 동안 저희 팀을 적어도 12건의 프로덕션 사건에서 구해줬으며, 230개 이상의 API 엔드포인트에서 99.97%의 가동 시간을 유지하는 데 도움이 되었습니다. 이는 이론이 아닙니다—새벽 3시에 페이지를 당한 경험이 많은 사람의 전투 검증된 현실입니다.
인증 및 권한 부여: 누구나 서둘러 지나치는 기초
여기 당신을 두렵게 할 통계가 있습니다: 제가 7개 회사의 API를 감사하는 동안 대략 60%가 고장난 권한 부여 논리를 가진 최소 한 개의 엔드포인트를 가지고 있었습니다. 인증이 아니라, 권한 부여입니다. 엔드포인트는 로그인 여부는 확인했지만, 특정 리소스에 접근할 수 있는지 여부는 제대로 확인하지 않았습니다.
제 인증 및 권한 부여 체크리스트는 명백하지만 종종 생략되는 기본 사항으로 시작합니다:
- 아무 인증 토큰 없이 테스트—401을 반환해야 합니다
- 만료된 토큰으로 테스트—401을 반환해야 하며, 500을 반환하면 안 됩니다
- 형식이 잘못된 토큰으로 테스트—401을 반환해야 하며, 크래시되어서는 안 됩니다
- 유효한 토큰이지만 잘못된 권한으로 테스트—403을 반환해야 합니다
- 다른 사용자를 위한 토큰으로 다른 사용자의 리소스를 액세스하려고 시도합니다
마지막 항목에서 흥미로운 일들이 발생합니다. 저는 URL에서 사용자 ID를 변경하기만 하면 다른 사용자의 결제 기록을 조회할 수 있는 엔드포인트를 발견한 적이 있습니다. 다른 사용자로 인증받는 상태에서도 말이죠. 해당 엔드포인트는 로그인이 되어 있는지 확인했지만, 요청한 사용자 ID가 인증된 사용자 ID와 일치하는지를 확인하지 않았습니다. 이것을 불안전한 직접 객체 참조 (IDOR)라고 하며, 충격적으로 흔합니다.
저는 토큰 갱신 흐름도 명시적으로 테스트합니다. 토큰이 요청 중에 만료되면 어떻게 될까요? API가 우아하게 처리합니까, 아니면 클라이언트를 이상한 상태로 남깁니까? 제가 본 시스템 중에는 POST 요청 중에 만료된 토큰이 401을 반환하지만 데이터는 여전히 부분적으로 데이터베이스에 기록되는 경우도 있었습니다. 이는 데이터 일관성에 대한 악몽입니다.
API 키를 사용하여 토큰 대신 인증하는 API의 경우, 키 회전이 제대로 작동하는지 확인합니다. 새로운 키를 생성할 수 있나요? 오래된 키는 즉시 작동이 멈추나요, 아니면 유예 기간이 있나요? 그 유예 기간이 문서화되어 있나요? 한 번은 키를 회전하는 API와 함께 일했는데, 아무도 알지 못했던 24시간 겹치는 기간이 있었습니다. 그로 인해 보안 감사에서 실패했습니다.
권한 부여 매트릭스는 저의 비밀 무기입니다. 모든 엔드포인트를 한 축에, 모든 사용자 역할을 다른 축에 작성한 스프레드시트를 만듭니다. 그런 다음 모든 조합을 체계적으로 테스트합니다. 번거롭지만, 제가 적용한 모든 프로젝트에서 100% 권한 부여 버그를 포착했습니다. 네, 100%. 과장이 아닙니다—모든 프로젝트에서 적어도 한 개의 엔드포인트에서 최소 한 역할의 권한 부여 논리가 잘못되었습니다.
요청 유효성 검사: 대부분의 버그가 실제로 존재하는 곳
저는 API 버그의 70%가 어디에서 시작되는지 추측해야 한다면, 요청 유효성 검사라고 하겠습니다. 개발자는 낙관적인 존재입니다—they는 입력이 합리적일 것이라고 가정하고 코드를 작성합니다. 그러나 인터넷과 API를 호출하는 시스템은 합리적이지 않습니다.
제 요청 유효성 검사 체크리스트는 exhaustive해야 합니다:
- 완전히 비어 있는 요청 본문 보내기—어떻게 될까요?
- 각 필수 필드에 대해 null 보내기
- 문자열 필드에 빈 문자열 보내기
- 공백만 있는 문자열 보내기
- 길이 제한보다 1자 긴 문자열 보내기
- 1000배 긴 문자열 보내기
- 양의 정수를 기대하는 필드에 대해 음수 보내기
- 제로가 유효하지 않을 수 있는 필드에 제로 보내기
- 정수 필드에 대해 소수 보내기
- 매우 큰 숫자 보내기 (정수 오버플로우 테스트)
- 매우 작은 숫자 보내기 (언더플로우 테스트)
- 문자열 필드에 특수 문자 보내기: 따옴표, 역슬래시, null 바이트, 유니코드
- SQL 주입 시도 보내기 (ORM을 사용하는 경우에도)
- 문자열 필드에 XSS 페이로드 보내기
- 데이터 유형 불일치 보내기 (숫자가 예상되는 곳에 문자열 등)
당신이 생각하고 있는 것이 뭔지 압니다: "사라, 그건 미친 짓이에요. 아무도 그걸 할 시간이 없어요." 하지만—저는 이 전체 체크리스트를 자동화했습니다. 모든 변형을 자동으로 생성하는 테스트 데이터 생성기가 있습니다. 초기 설정하는 데 약 2주가 걸렸지만, 이제는 새 엔드포인트에 대해 전체 스위트를 약 15분에 실행할 수 있습니다.
보상은 확실합니다. 지난달, 이 체크리스트는 65,535자보다 긴 문자열을 보낼 때 API 서버 전체를 크래시시키는 엔드포인트를 잡았습니다. 개발자는 데이터베이스가 길이 유효성을 처리할 것이라고 가정했지만, 데이터베이스는 조용히 잘라내도록 구성되어 있었고, 응용 프로그램 코드는 고정 크기 버퍼에 전체 문자열을 기록하려고 했습니다. 붕괴—세그멘테이션 오류, 서버 다운.
날짜 및 시간 필드에 대해서는 이러한 필드가 유독 끔찍하기 때문에 특별한 하위 체크리스트를 가지고 있습니다:
- 다양한 형식의 날짜 보내기 (ISO 8601, MM/DD/YYYY, DD/MM/YYYY 등)
- 유효하지 않은 날짜 보내기 (2월 30일, 13월, 32일)
- 아주 먼 과거의 날짜 보내기 (1900년, 1년)
- 아주 먼 미래의 날짜 보내기 (2100년, 9999년)
- 다른 시간대 오프셋이 있는 날짜 보내기
- 여름철 시간 변경 시 날짜 보내기
- 밀리초, 마이크로초, 나노초가 포함된 타임스탬프 보내기
여름철 시간 변경 시점은 저를 두 번 물게 했습니다. 두 번! 제가 배워야겠다고 생각할 수도 있지만, 이건 정말 이상한 엣지 케이스라 쉽게 잊어버리기 쉽습니다. 저는 이제 시계가 변경되는 날 오전 2시에 거래가 실행되는 특정 테스트를 가지고 있는데, 그때 이상한 일들이 발생합니다.
응답 유효성 검사: 신뢰하되 검증하라
대부분의 테스터들은 요청에 집중하고 응답은 거의 살펴보지 않습니다. 이는 잘못된 접근입니다. API의 응답은 세상과의 계약입니다. 응답이 일관성이 없거나 불완전하거나 잘못된 경우, 해당 계약이 파기된 것입니다.
| 테스트 카테고리 | 일반적인 실패 지점 | 예상 응답 | 실제 발생하는 일 |
|---|---|---|---|
| 인증 토큰 없음 | 오류 처리 누락 | 401 Unauthorized | 500 Internal Server Error 또는 노출된 데이터 |
| 만료된 토큰 | 토큰 검증 로직 | 401 Unauthorized | 500 오류 또는 침묵 실패 |
| 형식이 잘못된 토큰 | 입력 유효성 검사 | 401 Unauthorized | 애플리케이션 크래시 또는 스택 추적 노출 |
| 유효한 토큰, 잘못된 권한 | 권한 검사 | 403 Forbidden | 무단 데이터 접근으로 200 OK |
| 유효하지 않은 날짜 형식 | 입력 소독 | 400 Bad Request | 트랜잭션 연쇄 실패 |
제 응답 유효성 검사 체크리스트에는:
- 응답 상태 코드가 문서화된 동작과 일치하는지 확인
- 응답 콘텐츠 유형 헤더가 올바른지 확인
- 응답 본문 구조가 스키마와 일치하는지 확인
- 문서화된 모든 필드가 있는지 확인
- 문서화되지 않은 필드가 없는지 확인 (API 버전 관리에 중요)
- 필드 데이터 유형이 문서와 일치하는지 확인
- 필드 값이 문서화된 범위 내에 있는지 확인
- 타임스탬프가 올바른 시간대에 있는지 확인
- 페이지 매김 메타데이터가 올바르고 일관된지 확인
- 오류 응답에 유용한 오류 메시지가 포함되어 있는지 확인
- 오류 응답에 프로그래밍적 처리를 위한 오류 코드가 포함되어 있는지 확인
오류 메시지에 대한 그 전두 번째 사항이 중요합니다. "Error"라는 전체 오류 메시지를 반환하는 API를 본 적이 있습니다. 그것은 쓸모가 없습니다. 좋은 오류 메시지는 무엇이 잘못되었는지, 왜 잘못되었는지, 그리고 이상적으로는 그것을 어떻게 고칠 수 있는지를 알려줍니다. 이 두 개의 오류 응답을 비교해 보세요:
나쁨: {"error": "Invalid request"}
좋음: {"error": "Invalid request", "message": "필드 'email'은 필수이며 제공되지 않았습니다", "code": "MISSING_REQUIRED_FIELD", "field": "email"}
두 번째