Deep Dive: API 보안 기초

API는 현대 소프트웨어의 결합 조직으로, 모바일 앱, 마이크로서비스, 그리고 서드파티 통합을 구동한다. API가 애플리케이션 로직과 데이터를 직접 노출하기 때문에, API는 공격자들의 선호 대상이 되었다. API 보안은 이 인터페이스들을 설계하고, 테스트하고, 남용으로부터 방어하는 분야다.

API를 다르게 만드는 것

기존 웹 페이지와 달리, API는 JSON이나 XML 같은 구조화된 데이터 형식으로 통신하며, 종종 최소한의 인간 감시로 이루어진다. 이는 다음을 의미한다:

• 엔드포인트당 높은 공격 표면 — 각 API 경로는 본질적으로 자체 인증, 검증, 비즈니스 로직을 가진 미니 애플리케이션이다.
• 머신간 신뢰 — 서비스는 종종 유효한 토큰이 있는 요청이 정당하다고 가정하며, 공격자들은 토큰 탈취나 재생을 통해 이를 악용한다.
• 빠른 변화 — API는 빠르게 진화하고, 문서화되지 않거나 더 이상 사용되지 않는 "그림자" 엔드포인트가 보안 검토를 자주 빠져나간다.

일반적인 취약점 클래스

OWASP API Security Top 10은 프로덕션 시스템에서 관찰된 가장 널리 퍼진 문제들을 포괄한다:

• Broken Object Level Authorization (BOLA) — 사용자가 요청의 ID를 단순히 변경하여 다른 사용자의 데이터에 접근할 수 있다. 서버가 소유권을 검증하지 않기 때문이다.
• Broken Authentication — 약한 토큰 처리, 예측 가능한 세션 식별자, 또는 로그인 엔드포인트에 대한 누락된 속도 제한.
• 과도한 데이터 노출 — API가 전체 데이터베이스 객체를 반환하고 클라이언트가 민감한 필드를 필터링하는 것에 의존한다.
• 리소스 및 속도 제한 부재 — 제한이 없으면 공격자가 자격증명을 무차별 대입하거나 백엔드 리소스를 고갈시킬 수 있다.
• Broken Function Level Authorization — 역할 검사가 누락되거나 불일치하기 때문에 일반 사용자가 관리자 전용 엔드포인트에 도달한다.
• Mass Assignment — isAdmin 같은 클라이언트 제공 필드를 필터링 없이 직접 데이터베이스 모델에 수용한다.
• 보안 오류 설정 — 상세한 에러 메시지, 노출된 디버그 엔드포인트, 또는 누락된 보안 헤더.
• Injection — 새니타이징되지 않은 입력이 API 매개변수를 통해 SQL, NoSQL, 또는 커맨드 인터프리터에 도달한다.

인증 및 권한 부여 필수

인증은 누가 API를 호출하는지 확인한다. 권한 부여는 무엇을 수행할 수 있는지 확인한다. 강력한 API 보안은 모든 요청에서 두 계층이 독립적으로 적용되어야 한다:

• OAuth 2.0이나 OpenID Connect 같은 업계 표준 프로토콜을 사용하되, 커스텀 토큰 방식은 피한다.
• JWT를 제대로 검증한다 — 서명, 만료, 발급자, 대상 클레임을 확인하고, 서명되지 않은 토큰이나 alg: none 토큰을 신뢰하지 않는다.
• 객체 수준 검사를 서버측에서 적용한다: 리소스 ID를 참조하는 모든 요청은 호출자가 실제로 그 리소스를 소유하거나 접근 권한이 있는지 검증해야 한다.
• API 키와 서비스 계정에 최소 권한 원칙을 적용하여, 광범위한 접근 권한을 부여하기보다 좁게 범위를 정한다.

입력 검증 및 출력 제어

API 매개변수 — 헤더, 쿼리 문자열, 중첩 JSON 필드를 포함 — 를 모두 신뢰할 수 없는 입력으로 취급한다:

• 스키마 검증(예: JSON Schema 또는 OpenAPI 기반 검증기)을 사용하여 데이터 타입, 길이, 형식을 검증한다.
• 역직렬화 중에 mass assignment 공격을 방지하기 위해 예상 필드에 대해 허용 목록을 사용한다.
• 클라이언트가 정당하게 필요로 하는 필드만 반환하고, 응답에서 전체 내부 객체를 덤프하지 않는다.
• 스택 트레이스, 내부 경로, 또는 데이터베이스 세부 정보를 유출하지 않도록 에러 응답을 표준화한다.

속도 제한, 모니터링, 로깅

인증이 잘되어 있더라도 API는 남용 패턴으로부터 보호가 필요하다:

• 사용자당 및 IP당 속도 제한을 구현하여 무차별 대입과 스크래핑 시도를 약화시킨다.
• 인증 이벤트, 권한 부여 실패, 그리고 비정상적인 접근 패턴을 로깅하여 나중 분석에 대비한다.
• 민감한 엔드포인트에 대한 갑작스러운 요청 급증이나 예상 외의 지역에서의 접근 같은 비정상을 모니터링한다.
• 정확한 API 인벤토리를 유지한다 — 존재하지 않는 것을 보호할 수 없으므로, 더 이상 사용되지 않는 "그림자" 엔드포인트를 추적하고 폐기한다.

실용적인 테스트 접근 방식

API 보안은 일회성 감사가 아니라 지속적인 과정이다:

• API 특화 도구(예: Postman 컬렉션과 보안 스캐너 조합)를 CI/CD 파이프라인에 통합한다.
• 권한 부여 결함에 대한 수동 테스트를 수행한다. 자동화된 스캐너는 종종 BOLA와 비즈니스 로직 문제를 놓친다.
• API 문서(OpenAPI/Swagger 스펙)를 실제 구현과 동기화된 상태로 유지하여 테스트 중 맹점을 방지한다.
• 서드파티 API 통합을 자신의 코드와 같은 검토 기준으로 검토한다. 손상된 파트너 API는 공격 벡터가 될 수 있기 때문이다.

마무리

API 보안은 고전적인 웹 애플리케이션 보안 원칙과 규모의 머신간 통신이라는 고유한 도전을 혼합한다. 권한 부여를 올바르게 수행하고, 모든 입력을 검증하고, API 표면을 가시화 유지하는 것이 복원력 있는 방어의 기초다.

Korra Studio의 웹 애플리케이션 보안 및 인증 설계 관련 세그먼트를 살펴보아 이 개념들에 대한 더 깊이 있고 실습적인 이해를 구축하라.