이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
API 보안 설계에서 먼저 고려하는 건 인증·인가·입력 검증·전송 보안 네 가지입니다. 인증은 JWT나 OAuth2로 클라이언트를 확인하고, 인가는 역할 기반 접근 제어(RBAC)로 리소스 접근 범위를 제한합니다. 입력 검증은 SQL 인젝션·XSS를 막기 위해 입력값을 서버 측에서 화이트리스트 기준으로 검증하는 방식을 씁니다. 전송 보안은 HTTPS 강제와 HSTS 헤더 설정으로 처리합니다. 프로젝트에서는 Rate Limiting을 추가해서 동일 IP에서 단시간에 과도한 요청이 들어올 때 차단하는 로직을 구현했습니다.
보안은 하나의 계층으로 끝나지 않고, 여러 계층이 서로 보완하는 방식으로 설계해야 한다는 걸 배웠습니다. 각 계층이 뚫려도 다음 계층이 막는 '심층 방어' 원칙을 따릅니다.
API 보안에서 경계 기반 신뢰 모델의 한계를 처음 실감한 건, 내부 네트워크 서비스 간 통신에서 인증 없이 호출이 가능했던 구조를 발견했을 때였습니다. 외부 공격은 방어했지만, 서비스 내부에서 라우팅된 요청을 그대로 신뢰하는 설계였습니다.
이후 Zero-trust 원칙을 적용해 내부 서비스 간에도 mTLS로 상호 인증하는 구조로 바꿨습니다. 각 서비스가 클라이언트 인증서를 제시하고, CA가 이를 검증하는 방식으로 내부 서비스 위장 공격 경로를 닫았습니다. 인증서 관리 비용이 올라가는 트레이드오프가 있었는데, Vault를 사용해 단기 인증서 자동 갱신을 구현하면서 어느 정도 해소됐습니다.
보안은 신뢰 범위를 최소로 가져가는 것이 기본 원칙이라고 생각하고, 그 방향으로 설계 결정을 내립니다.
API 설계 중에 OWASP API Security Top 10을 체크리스트로 쓰기 시작한 건, 코드 리뷰에서 Broken Object Level Authorization 이슈를 놓쳤던 경험 때문이었습니다. 다른 사용자의 객체 ID를 직접 요청에 넣으면 접근이 됐는데, 인증은 통과했지만 인가 검사가 빠져 있었습니다. 그 이후로 엔드포인트마다 객체 소유권 검증 레이어를 명시적으로 추가했습니다.
보안 테스트도 OWASP ZAP으로 자동화 스캔을 CI에 넣어서, PR마다 기본 취약점 검사가 돌도록 구성했습니다. 완벽한 차단보다는 탐지 속도를 높이는 방향이 현실적이라고 생각해서, 이상 요청 패턴을 로깅하고 임계치 초과 시 알림이 오도록 했습니다.
보안은 설계 시점에 들어가야 하는 요구사항이고, 나중에 덧붙이는 건 항상 빈틈이 생긴다는 걸 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.