API Security 체크리스트: OAuth·JWT·Rate Limit·WAF까지 (실무 점검표)
API는 서비스의 “문”입니다. 문이 많아질수록(앱/웹/파트너/서드파티) 공격 표면도 커집니다. 특히 최근에는 API 키 노출, 권한 우회(BOLA), Rate Limit 부재 같은 “기본 실수”가 실제 사고로 이어지는 경우가 많습니다. 이 글은 개념 설명이 아니라, 실무에서 바로 적용 가능한 점검표 중심으로 정리합니다.
목 차
- API 보안에서 가장 많이 터지는 6가지 포인트
- 인증(Authentication): API Key vs OAuth2
- 인가(Authorization): BOLA/IDOR를 막는 설계
- 입력 검증·로그·모니터링(운영 보안)
- Rate Limit·WAF·봇 대응(트래픽 방어)
- 최종 점검표(배포 전/운영 중) + FAQ
1. API 보안에서 가장 많이 터지는 6가지 포인트
| 리스크 | 증상 | 핵심 대응 |
| BOLA/IDOR | URL/파라미터의 ID만 바꾸면 타인 데이터 조회/수정 | 서버에서 “소유권” 검증 |
| 인증 토큰 관리 | JWT 만료/갱신 정책 부재, 토큰 탈취 시 장기 악용 | 만료·회수·재발급 전략 |
| Rate Limit 부재 | 로그인/인증/검색 API에 무차별 요청, 비용 폭증 | IP/계정/토큰 단위 제한 |
| 입력 검증 부족 | SQLi/NoSQLi/SSRF/명령주입 등 2차 피해 | 화이트리스트 검증 |
| 과도한 에러 노출 | 스택트레이스/DB정보/내부 경로 노출 | 표준 에러 포맷 + 내부 로그 |
| 관측성 부족 | 침해 징후를 “나중에” 알게 됨 | 로그·알림·대시보드 |
결론은 단순합니다. “인증”만으로는 부족하고, “인가 + 제한 + 운영 관측”이 같이 있어야 합니다.
2. 인증(Authentication): API Key vs OAuth2
API Key는 “식별”에는 편하지만, 사용자가 늘고 권한이 복잡해지면 사고가 나기 쉽습니다. 가능하면 사용자/앱이 섞이는 서비스는 OAuth2(또는 OIDC) 기반이 안전합니다.
| 구분 | API Key | OAuth2/OIDC |
| 장점 | 구현이 단순 | 권한·범위(Scope)·표준 생태계 |
| 단점 | 노출 시 위험이 큼(회수/추적 어려움) | 설계/운영이 필요 |
| 권장 | 서버-서버/내부 시스템 | 사용자/파트너/외부 앱 연동 |
실무 팁: 토큰을 쓴다면 짧은 만료 + 갱신 토큰 + 회수(Blacklist) 전략을 반드시 포함하세요.
3. 인가(Authorization): BOLA/IDOR를 막는 설계
가장 흔한 사고는 “로그인 했으니 OK”라는 착각입니다. API는 요청한 자원이 ‘그 사람 것인지’를 서버에서 매번 확인해야 합니다.
필수 원칙
✔ 클라이언트가 보낸 userId/role을 “믿지 말 것”
✔ 서버에서 토큰 기반 사용자 식별 후, DB에서 소유권 체크
✔ 관리자 권한은 별도 정책(감사 로그/2FA/승인 흐름)로 분리
4. 입력 검증·로그·모니터링(운영 보안)
- 입력 검증: “허용 목록(화이트리스트)”이 기본 (길이/형식/범위/문자셋)
- 에러 처리: 사용자에게는 표준 에러 코드만, 내부 상세는 서버 로그로
- 감사 로그: 로그인/권한 변경/데이터 다운로드/관리자 작업은 별도 보관
- 모니터링: 401/403 급증, 특정 API 폭증, 비정상 User-Agent 등을 알림
5. Rate Limit·WAF·봇 대응(트래픽 방어)
수익/비용 관점에서도 API는 “트래픽 폭탄”이 오기 쉬운 지점입니다. 최소한 아래 3가지는 권장합니다.
- Rate Limit: IP + 계정 + 토큰 단위로 다층 제한
- WAF/Rules: OWASP 룰 기반 차단 + 민감 API는 강화 룰
- 봇 대응: 로그인/회원가입/검색 API에 CAPTCHA 또는 행동 기반 탐지
6. 최종 점검표(배포 전/운영 중) + FAQ
| No | 체크 항목 |
| 1 | 민감 API(로그인/결제/다운로드) 목록화 및 보호수준 분류 |
| 2 | 인가(소유권) 검증 로직이 모든 CRUD에 적용되었는가 |
| 3 | 토큰 만료/갱신/회수(탈취 대응) 정책이 있는가 |
| 4 | 입력 검증(형식/길이/범위) + 서버측 검증이 기본인가 |
| 5 | Rate Limit(다층) + 비정상 트래픽 알림이 있는가 |
| 6 | 감사 로그(관리자/권한 변경/대량 조회)가 별도 보관되는가 |
FAQ
Q1. JWT만 쓰면 안전한가요?
A. JWT는 “형식”일 뿐입니다. 인가(소유권 검증) + 만료/회수 + 제한이 같이 있어야 합니다.
Q2. Rate Limit은 어느 API에 먼저 걸어야 하나요?
A. 로그인/회원가입/비밀번호 재설정/검색/파일다운로드 API부터 우선 적용을 권장합니다.
※ 본 글은 보안 일반 가이드이며, 서비스 환경에 따라 세부 설정은 달라질 수 있습니다.
관련글(내 블로그) — 함께 읽으면 이해가 빠릅니다
'IT 실무 가이드 & 체크리스트' 카테고리의 다른 글
| [IT-보안점검] TLS/HTTPS 완벽 가이드: 인증서·암호화·HSTS·실수 체크리스트 (0) | 2026.01.18 |
|---|---|
| [IT-보안점검] LLM 보안 점검표: ‘이거’ 없으면 내부자료 그대로 새나갑니다 (1) | 2026.01.18 |
