API 보안 체크리스트

API 보안 체크리스트는 “했음” 표시가 아니라 설계 결정, 구현 위치, 테스트 증거, 배포 설정, 리뷰 기록을 연결하는 품질 게이트다.
새 API는 기본 허용이 아니라 기본 거부에서 시작한다. 인증, 객체 권한, 기능 권한, 입력 검증, rate limit, 로그, 오류 응답을 설계 단계부터 정한다.
체크리스트 항목은 반드시 증거를 남겨야 한다. 테스트 이름, 로그 event, 설정 diff, threat decision, risk acceptance owner가 없으면 완료가 아니다.

설계 전에는 actor, asset, entry point, trust boundary, abuse story, 실패 응답, 감사 로그를 먼저 적는다.
구현 중에는 request DTO allowlist, Bean Validation, method security, repository ownership 조건, error handler, log masking을 확인한다.
테스트는 성공 케이스보다 비소유자, 만료 token, 권한 없는 role, 예상 밖 필드, 잘못된 Origin, 반복 호출을 먼저 넣어 본다.
배포 전에는 HTTPS, CORS, CSRF, secret 주입, 보안 헤더, 로그 수집, alert, rollback 시 보안 설정 변화를 확인한다.
코드 리뷰 질문은 “이 값은 누가 만들었고 어디서 검증되는가”, “이 resource의 소유권은 어디서 확인되는가”, “실패는 어떤 로그로 남는가”로 시작한다.
위험을 수용해야 한다면 owner, 만료일, 보완 조건, 재검토 일정이 있어야 한다.

1. API 설계 전 보안 체크리스트: threat model과 API 계약을 먼저 정해 구현 중 보안 판단을 덜 흔들리게 한다.
1. 구현 중 보안 체크리스트: Controller, Service, Repository, logging, exception handling의 실제 코드 위치를 확인한다.
1. 테스트와 취약점 검증 체크리스트: 인증/인가/입력/브라우저/API abuse 검증 증거를 남긴다.
1. 배포 전 운영 보안 체크리스트: 운영 설정, secret, 모니터링, rollback, incident readiness를 검증한다.
1. 코드 리뷰 보안 질문: 리뷰어가 변경 diff를 공격 요청 관점으로 읽도록 질문을 구조화한다.

체크리스트가 길수록 안전하다고 생각하기 쉽다.
- 길지만 증거가 없으면 통과 의례가 된다.
- 항목마다 확인 방법과 실패 시 조치가 있어야 한다.
Spring Security 설정만 보면 충분하다고 생각하기 쉽다.
- FilterChain은 공통 인증과 일부 방어를 맡지만 객체 소유권, 업무 권한, DTO 경계는 애플리케이션 코드가 책임진다.
- 체크리스트는 Controller부터 Repository까지 따라가야 한다.
배포 전 체크는 인프라 팀만의 일이라고 생각하기 쉽다.
- CORS, secret, 로그 마스킹, error response, rate limit는 코드와 운영 설정이 함께 만든다.
- rollback이 더 위험한 설정을 되살릴 수도 있다.
리뷰 코멘트가 있으면 증거가 된다고 생각하기 쉽다.
- 코멘트는 토론 기록이고 증거는 테스트, 로그, 설정 diff, risk acceptance다.

API 보안 체크리스트의 완료 기준은 무엇인가?
- 각 항목에 테스트, 로그, 설정, 코드 위치, 담당자 같은 검증 증거가 연결되어 있는 것이다.
새 API 설계에서 먼저 물어야 하는 질문은 무엇인가?
- 누가 어떤 자산에 어떤 action을 하며, 그 권한과 입력은 어디서 검증되고, 실패는 어떻게 응답/기록되는가다.
위험 수용이 필요한 항목에는 무엇이 있어야 하는가?
- owner, 이유, 영향 범위, 만료일, 보완 조치, 재검토 일정이 있어야 한다.

동블