2022년 9월, 호주 2위 통신사 Optus에서 980만 명의 고객 데이터가 유출됐다.
공격 방법은 정교하지 않았다. 고객 ID가 1, 2, 3... 순서대로 증가하는 API가 인증 없이 인터넷에 노출돼 있었다. 공격자는 숫자를 하나씩 올리며 전체 고객 정보를 긁어갔다. 여권번호, 운전면허번호, 주소까지.
Optus는 이 사고로 1억(공개 사건 보고서 기준) 4천만 호주달러의 대응 비용을 지출했다.
같은 해, T-Mobile에서는 한 공격자가 보안이 미흡한 API를 41일간 악용해 3,700만 고객 정보를 탈취했다. T-Mobile은 이후 3억 5천만(공개 사건 보고서 기준) 달러 규모의 집단소송 합의금을 지불했다.
2024년 5월에는 Dell의 파트너 포털 API가 분당 5,000건(공개 사건 보고서 기준)의 요청에도 차단되지 않아 4,900만 고객 레코드가 3주에 걸쳐 유출됐다.
이 사건들의 공통점이 있다. 공격 대상은 웹사이트가 아니라 API였다.
Akamai의 2025년 보고서에 따르면, 전체 웹 트래픽의 71%가 API 호출이다. 2024년 한 해 동안 3,110억 건의 웹 공격이 발생했고, 그중 API 대상 공격은 1,500억 건을 넘었다. 전년 대비 33% 증가한 수치다.
BOLA 공격 흐름
OWASP(Open Worldwide Application Security Project)는 웹 보안 취약점을 정리하는 비영리 재단이다. OWASP Top 10이라고 하면 보통 웹 애플리케이션 취약점을 떠올리지만, API 전용 목록이 따로 있다.
OWASP API Security Top 10은 2019년에 처음 발표됐고, 2023년에 두 번째 버전이 나왔다.
웹 Top 10과 API Top 10은 다르다.
| 구분 | 웹 Top 10 | API Top 10 |
|---|---|---|
| 초점 | 브라우저 기반 공격 (XSS, 인젝션) | 인증·인가·비즈니스 로직 |
| 1위 | Broken Access Control | BOLA (객체 수준 인가 결함) |
| 특징 | UI 렌더링 취약점 포함 | 데이터 흐름과 접근 제어 중심 |
웹 애플리케이션은 사용자가 브라우저로 접근하기 때문에 UI 단에서 필터링이 가능하다. 하지만 API는 다르다. 누구든 HTTP 요청을 직접 보낼 수 있고, 프론트엔드의 보호막이 없다.
Salt Security의 2024년 보고서에 따르면, 기업의 95% 가 운영 중인 API에서 보안 문제를 경험했다. 그런데 "고급 수준의 API 보안 프로그램을 갖추고 있다"고 답한 기업은 7.5% 에 불과했다.
Traceable의 2025년 보고서에 따르면, 공격 시도의 88% 가 OWASP API Top 10 기법을 활용한다. 그중에서도 반복적으로 등장하는 3개가 있다.
BOLA(Broken Object Level Authorization)는 API Top 10의 1위다. 2019년부터 2023년까지 부동의 1위를 지키고 있다.
원리는 단순하다.
GET /api/users/1001 로 내 정보를 조회할 수 있다면, /api/users/1002로 남의 정보도 조회할 수 있는가?
서버가 "이 요청을 보낸 사람이 1002번 유저의 데이터를 볼 권한이 있는가?"를 확인하지 않으면 BOLA다.
실제 사례: Coinbase (2022년 2월)
암호화폐 거래소 Coinbase의 고급 트레이딩 API에서 치명적인 결함이 발견됐다. 자신이 소유하지 않은 계정을 출금 소스로 지정해 암호화폐를 거래할 수 있었다. 화이트햇 연구자가 발견해 ,000 버그바운티를 받았고, Coinbase는 6시간 동안 마켓을 중단했다.
쿠팡에서도 유사한 패턴이 발견된 바 있다. 퇴직자 JWT 키와 순차 ID 취약점이 결합되면 BOLA 공격이 대규모로 가능해진다.
API에 인증 자체가 없거나, 있어도 우회가 가능한 경우다.
실제 사례: Parler (2021년 1월)
소셜미디어 Parler의 API는 일부 엔드포인트에 인증이 아예 없었다. 연구자들이 70TB에 달하는 게시물, 이미지, 동영상을 인증 없이 스크래핑했다. 삭제된 게시물의 메타데이터까지 포함됐다.
인증 설계는 단순해 보이지만 실제로는 복잡하다. JWT 토큰 인증의 동작 원리와 보안 취약점이나 OAuth 2.0의 Authorization Code Flow를 이해하지 않고 구현하면 같은 실수를 반복하게 된다.
BFLA(Broken Function Level Authorization)는 BOLA와 비슷하지만 차원이 다르다. BOLA가 "남의 데이터를 보는 것"이라면, BFLA는 "관리자 전용 기능을 일반 사용자가 실행하는 것" 이다.
GET /api/users/1001 → 일반 사용자 기능
DELETE /api/admin/users/1001 → 관리자 기능
서버가 요청자의 역할(role)을 확인하지 않으면 일반 사용자가 관리자 기능을 호출할 수 있다.
실제 사례: 미국 텍사스 보험국
API의 함수 수준 권한 검증이 누락돼 200만(공개 사건 보고서 기준) 건의 보험 청구 개인정보가 노출됐다. 이 결함은 약 3년간 발견되지 않았고, 데이터 관리 감사 중 우연히 발견됐다.
2023년 버전에서 새로 추가되거나 크게 변경된 항목들이다.
Rate Limiting(요청 횟수 제한)이 없으면 공격자는 API를 무한히 호출할 수 있다.
실제 사례: Dell (2024년 5월)
Dell의 파트너 포털 API에 요청 제한이 없었다. 공격자는 분당 약 5,000건(공개 사건 보고서 기준), 3주간 총 수천만 건의 요청을 보내 4,900만 고객 레코드를 수집했다. Dell은 공격자로부터 4월 12~14일에 경고를 받았지만 2주 동안 대응하지 않았다.
기술적 취약점이 아니라 비즈니스 흐름 자체를 자동화해 악용하는 패턴이다. 2023년 버전에서 새로 추가됐다.
Nike는 한정판 스니커즈 출시 때 매달 120억 건의 봇 요청을 차단한다. 봇이 전체 응모의 상당 부분을 차지하기도 한다(Nike 공식 블로그 기준). 이건 SQL 인젝션도 아니고 인증 우회도 아니다. 정상적인 API를 비정상적인 규모로 호출하는 것이다.
내 서버가 호출하는 외부 API가 신뢰할 수 있는가? 이 질문을 하지 않으면 API8 취약점이 생긴다.
실제 사례: Ticketmaster/Snowflake (2024년 5월)
Ticketmaster는 Snowflake의 클라우드 API에 데이터를 저장하고 있었다. 공격자가 인포스틸러 악성코드로 탈취한 자격증명으로 Snowflake 계정에 접근했는데, MFA(다중인증)가 설정돼 있지 않았다. 5억 6천만(공개 사건 보고서 기준) 고객 레코드가 유출됐다. Santander 은행 등 다른 Snowflake 고객사도 피해를 입었다.
Notepad++ 공급망 공격: 업데이트 서버가 악성코드 배포지가 된 6개월와 동일한 패턴이다. 매일 신뢰하던 서드파티 서비스가 공격 벡터가 되는 것이다.
API 보안 다층 방어
| 항목 | 핵심 | 실제 사례 |
|---|---|---|
| API3: Broken Object Property Level Auth | API 응답에 불필요한 데이터까지 포함 | Peloton — 비공개 계정 포함 300만 사용자 전체 프로필 노출 (2021) |
| API7: SSRF | 서버를 속여 내부 시스템에 요청 전송 | Capital One — AWS 메타데이터 서비스 악용, 1억(공개 사건 보고서 기준) 600만 고객 레코드 유출 (2019) |
| API9: Improper Inventory Management | 잊혀진 API가 공격 대상이 됨 | Trello — 인증 없는 API로 1,500만 사용자 이메일 매칭 (2024) |
| API10: Security Misconfiguration | 기본 설정, 불필요한 HTTP 메서드, 과도한 에러 메시지 | DeepSeek — ClickHouse DB가 인증 없이 공개, 100만+ 로그 노출 (2025) |
API7(SSRF)은 Capital One 사건에서 8천만 달러의 벌금으로 이어졌다. 공격자는 클라우드 방화벽 무력화 공격, 3가지 실제 사례와 탐지법를 악용해 EC2 메타데이터 서비스에서 IAM 자격증명을 탈취했고, 이로써 S3 버킷 전체에 접근했다.
API9(Inventory Management)은 "좀비 API" 문제다. Salt Security에 따르면 기업의 70% 가 좀비 API를 "심각하거나 강한 우려 사항"으로 인식하고 있다. 클라우드 API가 남용되는 경로를 이해하면, 방치된 API가 왜 위험한지 알 수 있다.
Traceable의 2025년 보고서에 따르면, API 공격을 50% 이상 방어할 수 있는 기업은 13% 에 불과하다. 대부분은 공격이 발생한 뒤에야 인지한다.
방어의 핵심은 3개로 압축된다.
| 항목 | 점검 사항 |
|---|---|
| 인증 (Authentication) | 모든 엔드포인트에 인증 적용 여부 확인. "내부용"이라도 예외 없음 |
| 객체 수준 인가 (BOLA) | 모든 리소스 접근에 소유권 검증 로직 포함 여부 |
| 함수 수준 인가 (BFLA) | 역할 기반 접근 제어(RBAC) 적용. 관리자 기능은 별도 미들웨어로 보호 |
| 속성 수준 인가 (API3) | API 응답에서 요청자가 볼 수 없는 필드 제거 (allowlist 방식) |
| 항목 | 점검 사항 |
|---|---|
| Rate Limiting | IP별, 사용자별, 엔드포인트별 요청 한도 설정 |
| 입력 검증 | 요청 파라미터의 타입, 범위, 길이를 서버 측에서 검증 |
| 로깅 | 인증 실패, 인가 위반, 비정상 패턴을 실시간 탐지 |
| 봇 탐지 | 비즈니스 크리티컬 API에 CAPTCHA 또는 행동 분석 적용 |
Optus 사건의 핵심은 존재조차 잊힌 API가 인터넷에 노출돼 있었다는 점이다.
| 항목 | 점검 사항 |
|---|---|
| 인벤토리 | 운영 중인 모든 API 목록을 유지. 버전별, 환경별(dev/staging/prod) 관리 |
| 사용 중단 | 더 이상 사용하지 않는 API는 비활성화가 아닌 완전 제거 |
| 서드파티 검증 | 외부 API 호출 시 TLS 검증, 응답 스키마 검증, 타임아웃 설정 핵심 |
OWASP API Security Top 10에서 1위인 BOLA(OWASP 2023 발표 기준)(Broken Object Level Authorization)는 전체 API 취약점의 40%를 차지한다(Salt Security, 2024). 공격 방식은 단순하다. API 요청의 객체 ID를 변경하는 것만으로 타인의 데이터에 접근한다.
2023년 T-Mobile API 침해 사건에서 공격자는 /api/v1/customers/{id} 엔드포인트의 ID를 순차적으로 열거하여 3,700만 명의 고인정보를 탈취했다. BOLA 방어의 핵심은 모든 API 엔드포인트에서 요청자와 리소스 소유자의 일치를 검증하는 것이다. UUID v4 같은 추측 불가능한 식별자 사용도 권장되지만, 이는 보안이 아닌 난독화에 불과하다.
Mass Assignment(API3)은 클라이언트가 서버 측 객체의 속성을 직접 수정하는 공격이다. 사용자 프로필 업데이트 API에 {"name": "test", "role": "admin"}을 전송하여 권한을 상승시킨다. GitHub의 초기 Rails 기반 사이트가 이 취약점으로 공격당한 것은 유명한 사례다.
BFLA(Broken Function Level Authorization, API5)는 관리자 전용 엔드포인트에 일반 사용자가 접근하는 공격이다. /api/admin/users/delete를 직접 호출하거나, HTTP 메서드를 GET에서 DELETE로 변경하는 방식이다. API 게이트웨이에서 역할 기반 접근 제어(RBAC)를 강제하는 것이 효과적인 방어다.
API Rate Limiting은 무차별 대입 공격과 데이터 스크래핑을 방어하는 핵심 장치다. 하지만 공격자는 다양한 우회 기법을 사용한다. X-Forwarded-For 헤더 조작으로 IP 기반 제한을 우회하거나, 여러 API 키를 번갈아 사용하거나, 엔드포인트별 제한의 차이를 악용한다.
GraphQL API는 특히 취약하다. 단일 요청에 수십 개의 쿼리를 배치(batch)로 포함할 수 있어, 요청 횟수 기반 Rate Limiting이 무력화된다. 쿼리 복잡도(query complexity) 기반 제한과 깊이(depth) 제한을 함께 적용해야 한다.
OWASP ZAP, Burp Suite의 API 스캐닝 기능, 그리고 Postman의 보안 테스트 컬렉션은 API 보안 검증에 핵심적인 도구다. CI/CD 파이프라인에 API 보안 테스트를 통합하면 배포 전 취약점을 발견할 수 있다. Spectral, 42Crunch 같은 도구는 OpenAPI 스펙 기반으로 설계 단계에서 보안 문제를 감지한다.
API 보안의 첫 번째 방어선은 속도 제한이다. 무차별 대입 공격, 크리덴셜 스터핑, 데이터 스크래핑 모두 대량의 API 호출에 의존한다. Rate limiting은 클라이언트별, 엔드포인트별, 시간 단위별로 요청 수를 제한하여 이런 공격의 효율성을 크게 떨어뜨린다.
일반적으로 Token Bucket 알고리즘이 사용된다. 각 클라이언트에게 일정 수의 토큰이 할당되고, API 호출마다 토큰 하나가 소모된다. 토큰이 고갈되면 HTTP 429 Too Many Requests 응답이 반환된다. 이때 Retry-After 헤더로 재시도 가능 시점을 알려주는 것이 중요하다.
API 게이트웨이는 이런 보안 정책을 중앙에서 관리한다. Kong, AWS API Gateway, Apigee 같은 솔루션은 인증, 속도 제한, 요청 검증, 로깅을 한곳에서 처리한다. 개별 마이크로서비스에 보안 로직을 분산시키면 일관성이 깨지기 쉽다. 게이트웨이 패턴은 보안 정책의 단일 적용 지점(Single Enforcement Point)을 만든다.
REST API와 달리 GraphQL은 클라이언트가 쿼리 구조를 직접 정의한다. 이 유연성이 보안 위협이 된다. 중첩 쿼리(Nested Query) 공격이 대표적이다. { user { friends { friends { friends { ... } } } } } 같은 깊이 중첩된 쿼리는 서버의 CPU와 메모리를 폭발적으로 소모시킨다.
쿼리 깊이 제한(Query Depth Limiting)과 쿼리 복잡도 분석(Query Complexity Analysis)이 핵심이다. Apollo Server의 경우 depthLimit(10) 같은 미들웨어로 최대 깊이를 제한하고, 각 필드에 복잡도 점수를 부여하여 총합이 임계값을 초과하면 쿼리를 거부한다.
Introspection 비활성화도 중요하다. 프로덕션 환경에서 스키마 구조가 노출되면 공격자는 모든 타입과 필드를 파악하고 정밀한 공격을 설계할 수 있다. __schema 쿼리를 차단하는 것만으로 정보 수집 단계의 난이도를 높일 수 있다.
API 인증 방식의 선택은 보안 수준과 직결된다. API 키는 가장 단순하지만 가장 위험하다. 키가 유출되면 전체 접근 권한이 노출되며, 키 자체에는 만료 개념이 없다. GitHub의 경우 2024년 한 해 동안 공개 저장소에서 320만(공개 사건 보고서 기준) 개의 API 키를 탐지하여 무효화했다.
OAuth 2.0은 위임된 권한(Delegated Authorization)을 제공한다. 사용자의 자격증명을 직접 공유하지 않고 범위가 제한된 액세스 토큰을 발급한다. PKCE(Proof Key for Code Exchange) 확장은 모바일 앱처럼 클라이언트 시크릿을 안전하게 저장할 수 없는 환경에서 인가 코드 가로채기 공격을 방지한다.
JWT는 자체 포함(Self-contained) 토큰으로 서버 측 세션 저장소가 불필요하다. 하지만 토큰 취소가 어렵다는 근본적 한계가 있다. 짧은 만료 시간(15분 이하)과 리프레시 토큰의 조합, 또는 토큰 블랙리스트가 일반적인 대응 방안이다.
모놀리식 아키텍처에서 마이크로서비스로의 전환은 API 보안의 복잡도를 기하급수적으로 증가시켰다. 하나의 애플리케이션 내부 함수 호출이 네트워크를 통한 API 호출로 바뀌면서, 모든 서비스 간 통신이 잠재적 공격 표면이 됐다.
서비스 메시(Service Mesh)는 이 문제를 네트워크 계층에서 해결한다. Istio나 Linkerd 같은 서비스 메시는 모든 서비스 간 통신에 mTLS(mutual TLS)를 자동 적용한다. 각 서비스에 사이드카 프록시가 배치되어 인증, 암호화, 접근 제어를 애플리케이션 코드 변경 없이 수행한다.
제로 트러스트 API 보안은 네트워크 위치가 아닌 요청의 속성으로 신뢰를 결정한다. 내부 네트워크에서 온 요청이라도 유효한 토큰, 적절한 권한, 정상적인 호출 패턴을 모두 검증한다. Google의 BeyondCorp 모델이 이 접근의 대표적 구현이다. 모든 API 호출에 대해 호출자의 신원, 기기의 보안 상태, 요청의 맥락을 종합적으로 평가한다.
API 보안은 더 이상 선택이 아닌 핵심가 됐다. Gartner는 2025년까지 기업 웹 애플리케이션의 50% 이상이 API를 통해 데이터를 노출할 것으로 전망했다. API 보안 테스트를 CI/CD 파이프라인에 통합하고, 런타임 API 보호 솔루션을 배포하는 것이 현대적 애플리케이션 보안의 기본이 되고 있다. 특히 API 인벤토리 관리가 중요하다. 조직 내 존재하는 모든 API를 파악하지 못하면 보호할 수 없다. Shadow API(문서화되지 않은 API)와 Zombie API(더 이상 사용되지 않지만 활성 상태인 API)를 식별하고 관리하는 것이 첫 단계다.
Shadow API를 탐지하기 위해서는 네트워크 트래픽을 분석하여 문서화되지 않은 엔드포인트를 자동으로 발견하는 API Discovery 도구의 활용이 핵심적이다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.