API 보안
더 많은 작업
- API Security; API 보안
- 애플리케이션 프로그래밍 인터페이스(API)를 통해 노출되는 데이터와 기능을 인증·인가·자원 통제·입력 검증·인벤토리 관리로 보호하는 활동
현대 서비스는 모바일 앱, 웹 프런트엔드, 협력사 연동, 마이크로서비스 간 호출이 모두 API를 거친다. 화면이 없는 API는 사용자 인터페이스가 걸러 주던 제약이 없어서, 공격자는 요청의 객체 ID나 속성 값을 바꿔 보내는 것만으로 다른 사람의 데이터에 닿을 수 있다. 그래서 API 보안의 핵심은 암호화보다 객체·속성·기능 단위의 인가와 자원 소비 통제에 있다.
CISSP 시험 개요에서 API는 두 곳에 나온다. 3.5(보안 아키텍처의 취약점 평가와 완화)의 마이크로서비스 항목은 아키텍처 관점에서, 8.5(시큐어 코딩 지침과 표준)의 API 보안 항목은 개발 관점에서 다룬다. 이 문서는 두 관점을 함께 정리한다.
OWASP API Security 프로젝트가 2023년에 발표한 API 보안 위험 10가지이다. 웹 애플리케이션용 OWASP Top 10과는 별개의 목록이다.
| 순위 | 항목 (영문) | 내용 | 주요 대책 |
|---|---|---|---|
| API1 | 객체 수준 인가 실패 (BOLA, Broken Object Level Authorization) | 요청의 객체 ID만 바꾸면 남의 주문·계좌·파일에 접근된다. 가장 흔하고 피해가 큰 유형이다. | 객체에 접근하는 모든 함수에서 "이 사용자가 이 객체의 소유자이거나 권한이 있는가"를 서버에서 검사, 추측하기 어려운 ID 사용 |
| API2 | 인증 실패 (Broken Authentication) | 토큰 검증 누락, 약한 비밀번호 허용, 무차별 대입 무방비 등으로 다른 사용자로 위장된다. | 표준 인증 프레임워크 사용, 토큰 서명·만료 검증, 로그인 시도 제한, 다중 인증 |
| API3 | 객체 속성 수준 인가 실패 (BOPLA, Broken Object Property Level Authorization) | 응답에 불필요한 속성이 노출되거나(과도한 데이터 노출), 요청으로 바꾸면 안 되는 속성(권한, 가격)을 바꿀 수 있다(대량 할당). 2019년판의 두 항목을 합친 것이다. | 응답 필드 허용 목록, 요청에서 수정 가능한 속성 명시, 스키마로 거르기 |
| API4 | 무제한 자원 소비 (Unrestricted Resource Consumption) | 대역폭·CPU·메모리뿐 아니라 건당 과금되는 SMS·메일·외부 API 호출까지 소진시켜 서비스 거부나 비용 폭증을 일으킨다. | 속도 제한, 페이지 크기·업로드 크기 상한, 실행 시간 제한, 과금 연동 기능의 사용 한도 |
| API5 | 기능 수준 인가 실패 (BFLA, Broken Function Level Authorization) | 일반 사용자가 관리자용 엔드포인트나 다른 HTTP 메서드(예: GET 대신 DELETE)를 호출할 수 있다. | 기본 거부, 역할별 기능 권한을 중앙에서 일관되게 검사 |
| API6 | 민감한 비즈니스 흐름에 대한 무제한 접근 (Unrestricted Access to Sensitive Business Flows) | 구현 버그가 없어도 한정 수량 구매, 예약, 쿠폰 발급 같은 흐름을 자동화 도구로 대량 실행해 사업에 피해를 준다. | 위험한 흐름 식별, 기기 지문·사람 확인·비정상 패턴 탐지, 흐름별 사용 한도 |
| API7 | 서버 측 요청 위조 (SSRF, Server Side Request Forgery) | 사용자가 준 URL을 검증 없이 서버가 가져오면, 방화벽 안쪽 내부 시스템이나 클라우드 메타데이터 서비스로 요청이 간다. | 목적지 허용 목록, 리다이렉트 비활성화, 응답을 그대로 돌려주지 않기, 아웃바운드 네트워크 분리 |
| API8 | 보안 설정 오류 (Security Misconfiguration) | 불필요한 HTTP 메서드, 과도한 CORS 허용, 상세 오류 메시지, 패치 누락, 전송 구간 암호화 누락 등이다. | 하드닝 기준과 자동 점검, 환경별 설정 검토 |
| API9 | 부적절한 인벤토리 관리 (Improper Inventory Management) | 문서에 없는 구버전·테스트용·디버그 API가 운영망에 남아 공격 통로가 된다. | 호스트·버전·환경·데이터 흐름까지 포함한 API 목록 유지, 구버전 폐기 계획 |
| API10 | 안전하지 않은 API 소비 (Unsafe Consumption of APIs) | 외부 협력사 API에서 받은 데이터를 사용자 입력보다 더 믿고 검증 없이 처리한다. 공격자는 대상 대신 연동된 제3자를 노린다. | 외부 API 응답도 입력 검증, 전송 암호화, 리다이렉트 맹목 추종 금지, 자원 제한 |
| 대책 | 설명 |
|---|---|
| 인증과 인가 | 인증은 OAuth 2.0·OpenID Connect 같은 표준을 쓰고, 토큰(JWT 등)의 서명·발급자·대상·만료를 매번 검증한다. 인가는 게이트웨이에서 끝내지 말고 객체와 기능 단위로 서비스 안에서 다시 검사한다. API 키는 호출 애플리케이션 식별용이지 사용자 인증 수단이 아니다. |
| 속도 제한 (rate limiting) | 클라이언트·사용자·IP별 호출 횟수를 제한한다. 한도를 넘으면 HTTP 429(Too Many Requests)로 응답하는 방식이 흔하다(HTTP 429). 비용이 큰 작업과 민감한 흐름에는 별도 한도를 둔다. |
| 입력 검증 | 형식·길이·범위·문자 집합을 허용 목록 방식으로 검사한다. SQL 인젝션 같은 주입 공격은 매개변수화 질의로 막는다. |
| 스키마 검증 | OpenAPI 명세나 JSON 스키마로 요청·응답의 구조를 정의하고, 정의되지 않은 필드는 거부한다. 대량 할당과 과도한 데이터 노출(API3)을 함께 줄인다. |
| API 게이트웨이 | 인증 토큰 검증, 속도 제한, 스키마 검증, 로깅을 한곳에서 일관되게 적용하는 관문이다. 다만 게이트웨이만으로 객체 수준 인가(BOLA)는 해결되지 않는다. |
| 웹 방화벽 | 알려진 공격 패턴을 걸러 주는 보조 통제이다. 비즈니스 로직 결함은 막지 못한다. |
| 인벤토리 | 모든 API의 소유자, 버전, 배포 환경, 처리 데이터 등급, 인증 방식을 목록으로 관리하고 사용하지 않는 버전은 폐기한다. |
| 로깅과 모니터링 | 인가 실패, 비정상적인 ID 순회, 과도한 호출을 기록하고 탐지 규칙을 둔다. |
NIST SP 800-228(클라우드 네이티브 시스템의 API 보호 지침)은 API 위험 요소를 개발 단계와 실행 단계로 나누고, 실행 전(pre-runtime) 통제와 실행 중(runtime) 통제를 기본·고급으로 구분해 점진적·위험 기반으로 적용하도록 권고한다.
마이크로서비스 구조에서는 외부 사용자의 요청(남북 트래픽)뿐 아니라 서비스끼리 주고받는 내부 호출(동서 트래픽)도 보호해야 한다. 내부망이라고 무조건 믿으면 한 서비스가 뚫렸을 때 측면 이동을 막을 수 없다. 제로 트러스트 관점에서는 내부 호출도 인증한다.
상호 TLS(mTLS, mutual TLS)는 서버만 인증서를 제시하는 일반 TLS와 달리 클라이언트와 서버가 서로 인증서를 제시해 상호 인증하는 방식이다. NIST SP 800-204A는 서비스 메시 구조에서 서비스 프록시끼리 mTLS 세션으로만 통신하도록 권고하고, 각 서비스의 신원을 인증서의 주체 이름(subject name)이나 주체 대체 이름(SAN)에 담도록 한다.
| 구분 | 일반 TLS | mTLS |
|---|---|---|
| 인증 방향 | 서버만 인증 | 서버와 클라이언트 모두 인증 |
| 주 사용처 | 브라우저와 웹 서버 | 서비스 간 호출, 협력사 B2B 연동, OAuth 클라이언트 인증 |
| 운영 부담 | 서버 인증서만 관리 | 모든 서비스의 인증서 발급·갱신·폐기 자동화 필요 |
| 구현 방식 | 애플리케이션 또는 로드밸런서 | 서비스 메시의 사이드카 프록시가 대신 처리하는 경우가 많음 |
mTLS는 "누가 호출했는가"를 확인할 뿐 "그 호출이 허용되는가"는 따로 판단해야 한다. 서비스 신원에 기반한 인가 정책을 함께 둔다.
생성형 AI 서비스와 AI 에이전트는 대부분 API로 호출되고, 에이전트는 다시 다른 API를 도구로 호출한다. 에이전트에 넓은 권한의 API 토큰을 주면 프롬프트 인젝션 한 번으로 BOLA·BFLA와 같은 결과가 생길 수 있다. 에이전트도 비인간 신원으로 보고 최소 권한 원칙, 호출 한도, 감사 로그를 적용한다.
- API 보안 사고의 가장 흔한 원인은 암호화 부재가 아니라 인가 실패이다. 객체 단위(BOLA)와 기능 단위(BFLA)를 구분하고, 속성 단위(BOPLA)는 과도한 노출과 대량 할당을 합친 것임을 기억한다.
- "API 남용을 가장 먼저 줄이는 통제"를 묻으면 속도 제한과 인증을, "구버전 API가 노출된 사고의 근본 대책"을 묻으면 인벤토리 관리를 고른다.
- 흔한 오답: API 게이트웨이나 웹 방화벽을 두면 인가 문제가 해결된다고 보는 것. 객체 수준 인가는 서비스 코드에서 검사해야 한다.
- 흔한 오답: API 키를 사용자 인증 수단으로 보는 것. API 키는 애플리케이션 식별에 가깝고 유출되기 쉽다.
- 서비스 간 통신 보호는 mTLS로 상호 인증하고, 그 위에 서비스 신원 기반 인가를 둔다.
- OWASP Top 10 API Security Risks – 2023 – OWASP API Security Project
- NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems – NIST
- NIST SP 800-204A, Building Secure Microservices-based Applications Using Service-Mesh Architecture – NIST
- NIST SP 800-204, Security Strategies for Microservices-based Application Systems – NIST
- RFC 6585, Additional HTTP Status Codes – IETF