日本語에서 번역 • 원문 보기 
"API 키나 토큰으로 인증하고 있으니 안전합니다."
"내부 API이기 때문에 외부에서 공격받을 수 없습니다."
"인증 기능을 구현했고, 앱 쪽은 내가 처리할게."
- 인증은 보안의 출발점일 뿐입니다.
인증을 통과한 후에는 위협이 몇 개인지 알면 인식이 달라집니다.
1. 인증 이후 다가오는 5가지 위협
위협 (1): 승인 결함 (BOLA/IDOR)
이 문제는 인증된 사용자 A가 사용자 B의 데이터에 접근할 수 있는 경우입니다.
파손 예시
/api/invoices/12345 받아보세요
사용자 A는 사용자 B의 ID만 변경하면 청구서를 받을 수 있습니다.
/api/invoices/12346 받아보세요
대응책: 각 요청마다 서버 측에서 이 사용자가 실제로 이 자원에 접근할 수 있는지 확인하세요.
위협 (2): 속도 제한 부재
만약 인증된 API에 초당 10,000개의 요청을 계속 보내면:
- 서비스 다운 (DoS)
- 무차별 대입 데이터 탐색 가능해
- 비용 폭발 (클라우드 API의 경우)
위협 (3): 입력 검증 부족
API 입력 매개변수를 신뢰하고 직접 DB에 전달하면 SQL 인젝션과 명령어 인젝션이 온상이 됩니다.
위협 (4): 민감한 정보 대응 유출
JSON
깨는 예: 필요 이상으로 많은 정보를 반환하는 것
{
"user_id": "123",
"이메일": "user@example.com",
"password_hash": "...", // 하지 마
"internal_role": "관리자", // 하지 마
"api_key": "sk-..." // 절대 필수 사항이 아닙니다
}
위협 (5): 감사 기록 부재
누가, 언제, 어떤 API, 어떤 매개변수를 기록하지 않으면, 사고가 발생한 후 조사가 불가능합니다.
2. 권한 설계: 항상 모든 요청을 검증하세요
OWASP의 상위 10대 API 보안 중 상위권은 Broken Object Level Authorization(BOLA)입니다.
안전 설계 포인트:
- 자원 ID에 DB 일련번호 대신 UUID를 사용함 (추측하기 어렵게)
- 접근 전에 이 리소스가 서버 측에서 해당 사용자에게 속하는지 반드시 확인하세요
- 프레임워크에 구애받지 않고 애플리케이션 계층에서 명시적으로 구현됨
3. 속도 제한 구현
기본적으로 API 게이트웨이 또는 미들웨어 계층에서 구현됩니다.
디자인 포인트:
- 사용자별과 IP별 모두 제한
- 제한에 막히면 '429 Too Many Requests'를 반환하고 이유를 명시하세요
- 제한은 API의 특성(특히 인증 API의 경우)에 따라 설정됩니다.
4. 감사 기록: 기록할 내용
API 감사 로그에 포함해야 할 최소 항목:
- 요청 시간, 엔드포인트, HTTP 메서드
- 인증 사용자 ID
- 클라이언트 IP 주소
- 응답 코드
- 요청 본문의 크기 (종종 본문 제외)
- 처리 시간
이를 Sentinel 및 Splunk와 통합함으로써 API 계층에서 이상 현상을 감지할 수 있습니다.
5. 이상 현상 탐지: API를 다르게 사용하는 방법
일반적인 API 사용 패턴을 학습하고 편차를 감지합니다.
이상 패턴의 예시:
- 특정 사용자가 한밤중에 계속해서 많은 수의 GET 요청을 보냅니다
- 평소에 사용하지 않는 엔드포인트에 대한 접근 권한이 갑자기 증가했습니다
- 지리적으로 비자연적인 위치에서의 API 접근
6. 컬러크루 시큐리티의 접근 방식
Colorkrew Security는 API 보안을 위한 설계 검토 및 구현 지원을 제공합니다.
**API 보안은 인증에서 시작됩니다. **
권한, 속도 제한, 감사 로그, 이상 감지 등 '깨지지 않는 설계'를 함께 만들어 봅시다.