OWASP API Security Top 10(2023)

OWASP API Security Top 10 2023. 웹용 Top 10과는 다른, API에 특화된 보안 위협 표준. 상위권을 점령한 인가(Authorization) 문제부터 비즈니스 흐름 악용까지, 백엔드 API 개발자가 알아야 할 10가지를 공격 예시와 대응 코드로 정리한다.

---

들어가며

지난 글에서 웹 애플리케이션용 OWASP Top 10:2025를 다뤘다. 그런데 OWASP에는 API에 특화된 별도의 Top 10이 있다. 바로 OWASP API Security Top 10이다.

두 문서는 다르다.
OWASP Top 10 (웹): 웹 애플리케이션 전반의 위협. 2017 → 2021 → 2025.
OWASP API Security Top 10 (API): REST·GraphQL 같은 API에 특화된 위협. 2019 → 2023.
이름이 비슷해 헷갈리지만, 대상과 항목이 다른 별개의 문서다. 이 글은 API 버전(2023)을 다룬다.

요즘처럼 프론트와 백엔드가 분리되고, 마이크로서비스와 모바일 앱이 API로 통신하는 환경에서는 API 보안이 곧 서비스 보안이다. 흥미로운 점은, API 보안의 핵심이 대부분 인가(Authorization) 에 있다는 것이다. 상위 5개 중 3개가 인가 관련 항목이다.

예시는 Java/Spring 기준이다.

---

2019 → 2023, 무엇이 바뀌었나

API 버전은 2019년 첫 발간 후 4년 만인 2023년에 개정됐다. 주요 변화는 이렇다.

• 신규: API6(민감한 비즈니스 흐름 무제한 접근), API7(SSRF), API10(안전하지 않은 API 소비)
• 통합: 기존 "과도한 데이터 노출"과 "Mass Assignment"가 API3(객체 속성 수준 인가)로 합쳐짐
• 확장: "리소스 부족·속도 제한"이 API4(무제한 리소스 소비)로 범위 확대

전체 목록은 다음과 같다.

순위	항목	분류
API1	Broken Object Level Authorization (BOLA)	인가
API2	Broken Authentication	인증
API3	Broken Object Property Level Authorization	인가
API4	Unrestricted Resource Consumption	자원
API5	Broken Function Level Authorization (BFLA)	인가
API6	Unrestricted Access to Sensitive Business Flows	설계
API7	Server Side Request Forgery (SSRF)	입력
API8	Security Misconfiguration	설정
API9	Improper Inventory Management	관리
API10	Unsafe Consumption of APIs	외부연동

---

API1. Broken Object Level Authorization (BOLA) — 객체 수준 인가 실패

API 보안의 부동의 1위. 요청한 사용자가 그 객체에 접근할 권한이 있는지 확인하지 않을 때 발생한다. 웹 Top 10의 IDOR와 같은 뿌리다.

// 취약: id로 조회만 하고 소유자 확인 없음
@GetMapping("/api/accounts/{accountId}")
public Account getAccount(@PathVariable Long accountId) {
    return accountRepository.findById(accountId).orElseThrow();
    // accountId를 1씩 바꾸면 남의 계좌가 그대로 조회된다
}

// 대응: 요청자가 해당 객체의 소유자인지 항상 검증
@GetMapping("/api/accounts/{accountId}")
public Account getAccount(@PathVariable Long accountId,
                          @AuthenticationPrincipal UserDetails user) {
    Account account = accountRepository.findById(accountId).orElseThrow();
    if (!account.getOwnerId().equals(user.getId())) {
        throw new AccessDeniedException("접근 권한이 없습니다");
    }
    return account;
}

대응 요약: 모든 객체 접근에 소유권을 검증한다.
순차적 정수 ID 대신 추측하기 어려운 UUID를 쓰는 것도 방어에 도움이 된다(근본 해결은 아니지만).

---

API2. Broken Authentication — 인증 실패

인증 메커니즘이 잘못 구현된 경우다. 토큰 검증 누락, 약한 비밀번호 허용, JWT 만료 미검증 등이 포함된다.

// 취약: JWT 서명만 보고 만료(exp)를 검증하지 않음
Claims claims = Jwts.parser().verifyWith(key).build()
        .parseSignedClaims(token).getPayload();
// 만료된 토큰도 통과 → 탈취된 토큰이 영원히 유효

// 대응: 만료 검증은 jjwt가 자동으로 하지만, 예외를 명시적으로 처리
try {
    Claims claims = Jwts.parser().verifyWith(key).build()
            .parseSignedClaims(token).getPayload();
} catch (ExpiredJwtException e) {
    throw new UnauthorizedException("토큰이 만료되었습니다");
} catch (JwtException e) {
    throw new UnauthorizedException("유효하지 않은 토큰입니다");
}

대응 요약: 검증된 인증 프레임워크를 쓰고, 토큰 만료·서명을 빠짐없이 검증한다.
로그인 무차별 대입에 속도 제한을 걸고, 민감 정보 변경 시 재인증을 요구한다. (이전 JWT 인증 글 참고)

---

API3. Broken Object Property Level Authorization — 객체 속성 수준 인가 실패

객체 접근은 허용되지만, 그 객체의 특정 속성까지는 통제하지 않는 경우다.
2019년의 "과도한 데이터 노출"과 "Mass Assignment"가 여기로 합쳐졌다.

// 취약: 요청 본문을 엔티티에 그대로 바인딩 (Mass Assignment)
@PatchMapping("/api/users/{id}")
public User update(@PathVariable Long id, @RequestBody User body) {
    User user = userRepository.findById(id).orElseThrow();
    user.setName(body.getName());
    user.setRole(body.getRole());   // 사용자가 role=ADMIN 을 보내면 권한 상승!
    return userRepository.save(user);
}

// 대응: 수정 가능한 속성만 받는 전용 DTO 사용
public record UpdateUserRequest(String name) {}   // role은 아예 받지 않음

@PatchMapping("/api/users/{id}")
public User update(@PathVariable Long id, @RequestBody UpdateUserRequest req) {
    User user = userRepository.findById(id).orElseThrow();
    user.setName(req.name());   // 허용된 필드만 변경
    return userRepository.save(user);
}

대응 요약: 응답은 필요한 속성만 담은 DTO로 내보내고(과도한 노출 방지),
요청도 수정 허용 속성만 받는 DTO로 받는다(Mass Assignment 방지). 엔티티를 그대로 입출력에 노출하지 않는다.

---

API4. Unrestricted Resource Consumption — 무제한 리소스 소비

속도 제한이 없어 API가 자원을 무제한으로 소비하는 경우다. DoS 공격이나 과금 폭탄으로 이어진다.

// 대응: Resilience4j 등으로 속도 제한
@RateLimiter(name = "api", fallbackMethod = "fallback")
@GetMapping("/api/search")
public List<Result> search(@RequestParam String query,
                           @RequestParam(defaultValue = "20") int size) {
    int limited = Math.min(size, 100);   // 페이지 크기 상한도 강제
    return searchService.search(query, limited);
}

대응 요약: 요청 횟수·페이로드 크기·페이지 크기·실행 시간에 상한을 둔다.
무거운 연산(파일 업로드, 외부 호출)에는 타임아웃과 쿼터를 적용한다.

---

API5. Broken Function Level Authorization (BFLA) — 함수 수준 인가 실패

객체가 아니라 기능(엔드포인트) 자체에 대한 권한 검증이 빠진 경우다. 일반 사용자가 관리자 API를 호출할 수 있는 상황이다.

// 취약: 관리자 엔드포인트에 권한 검사 없음
@DeleteMapping("/api/admin/users/{id}")
public void deleteUser(@PathVariable Long id) {
    userRepository.deleteById(id);   // 누구나 호출 가능
}

// 대응: 메서드 수준 권한 검사
@PreAuthorize("hasRole('ADMIN')")
@DeleteMapping("/api/admin/users/{id}")
public void deleteUser(@PathVariable Long id) {
    userRepository.deleteById(id);
}

대응 요약: 관리자/일반 기능을 명확히 분리하고, 엔드포인트마다 역할 기반 권한을 검증한다.
기본은 거부(deny by default), 권한이 있는 역할만 명시적으로 허용한다.

---

API6. Unrestricted Access to Sensitive Business Flows — 민감한 비즈니스 흐름 무제한 접근 (신규)

기술적 취약점은 없지만, 비즈니스 흐름이 자동화로 악용되는 경우다.
한정판 상품을 봇이 싹쓸이하거나, 예약을 대량 선점하는 식이다.

// 대응 예: 민감 흐름에 봇 방어 + 구매 수량 제한
@PostMapping("/api/orders/limited-edition")
public Order purchase(@AuthenticationPrincipal UserDetails user,
                      @RequestBody OrderRequest req) {
    if (!captchaService.verify(req.captchaToken())) {   // 봇 차단
        throw new BadRequestException("인증에 실패했습니다");
    }
    if (orderService.countToday(user.getId()) >= 2) {   // 1인당 수량 제한
        throw new BusinessException("구매 한도를 초과했습니다");
    }
    return orderService.create(user, req);
}

대응 요약: 흐름이 악용될 가능성을 설계 단계에서 식별한다.
봇 탐지(CAPTCHA, 디바이스 핑거프린팅), 1인당 수량·빈도 제한, 비정상 패턴 탐지를 적용한다.

---

API7. Server Side Request Forgery (SSRF) — 서버 측 요청 위조 (신규)

API가 사용자가 준 URL로 서버가 요청을 보내게 만드는 공격이다.
내부망이나 클라우드 메타데이터 주소에 접근당할 수 있다. (웹 2025판에서는 접근 제어로 흡수됐지만, API에서는 별도 항목이다.)

// 취약: 사용자가 준 URL을 그대로 호출
@PostMapping("/api/fetch-image")
public byte[] fetchImage(@RequestBody String imageUrl) {
    return restClient.get().uri(imageUrl).retrieve().body(byte[].class);
    // imageUrl=http://169.254.169.254/... → 클라우드 자격증명 탈취
}

// 대응: 허용된 도메인만 통과 + 내부 IP 차단
private static final Set<String> ALLOWED = Set.of("cdn.example.com");

@PostMapping("/api/fetch-image")
public byte[] fetchImage(@RequestBody String imageUrl) {
    URI uri = URI.create(imageUrl);
    if (!ALLOWED.contains(uri.getHost()) || isInternalAddress(uri.getHost())) {
        throw new BadRequestException("허용되지 않은 주소입니다");
    }
    return restClient.get().uri(uri).retrieve().body(byte[].class);
}

대응 요약: 외부 URL은 허용 목록(allowlist)으로만 받고, 내부망·메타데이터 주소(169.254.169.254, localhost, 사설 IP 대역)를 차단한다. 리다이렉트도 따라가지 않도록 한다.

---

API8. Security Misconfiguration — 보안 설정 오류

불필요하게 열린 메서드, 누락된 보안 헤더, 과도한 CORS 허용, 상세 에러 노출 등. 웹 버전과 같은 맥락이지만 API에서 특히 CORS가 자주 문제다.

// 취약: 모든 출처 허용
config.setAllowedOrigins(List.of("*"));
config.setAllowCredentials(true);   // 와일드카드 + 인증정보 = 위험

// 대응: 신뢰하는 출처만 명시
config.setAllowedOrigins(List.of("https://app.example.com"));
config.setAllowedMethods(List.of("GET", "POST"));
config.setAllowCredentials(true);

대응 요약: CORS는 신뢰 출처만 허용하고, 불필요한 HTTP 메서드를 막는다.
보안 헤더를 적용하고, 에러 응답에 스택트레이스나 내부 정보를 노출하지 않는다.

---

API9. Improper Inventory Management — 부적절한 인벤토리 관리

어떤 API가 어디서 돌고 있는지 파악이 안 되는 경우다.
문서화 안 된 옛 버전(/api/v1), 테스트 서버, 폐기했어야 할 엔드포인트가 방치되며 공격 표면이 된다.

취약 예:
  /api/v3/users   ← 최신, 보안 패치 적용됨
  /api/v1/users   ← 옛 버전, 인증 약함, 아직 살아 있음 ← 공격 대상

대응 요약: 모든 API 엔드포인트와 버전을 문서화(OpenAPI/Swagger)하고 목록을 관리한다.
더 이상 안 쓰는 버전은 명시적으로 폐기(deprecate)하고 종료한다. 운영/테스트 환경을 분리한다.

---

API10. Unsafe Consumption of APIs — 안전하지 않은 API 소비 (신규)

내가 만든 API가 아니라, 내가 호출하는 외부(서드파티) API를 너무 신뢰할 때의 위험이다.
공격자는 직접 공격하기 어려운 대상 대신, 그 대상이 연동한 외부 서비스를 노린다.

// 취약: 외부 API 응답을 검증 없이 그대로 신뢰
ExternalResponse res = restClient.get().uri(thirdPartyUrl)
        .retrieve().body(ExternalResponse.class);
processPayment(res.getAmount());   // 외부 응답을 그대로 결제에 사용

// 대응: 외부 응답도 내 입력처럼 검증
ExternalResponse res = restClient.get().uri(thirdPartyUrl)
        .retrieve().body(ExternalResponse.class);
if (res.getAmount() == null || res.getAmount().signum() < 0) {
    throw new IntegrationException("외부 응답이 올바르지 않습니다");
}
processPayment(res.getAmount());

대응 요약: 외부 API와도 TLS로만 통신하고, 받은 데이터를 사용자 입력과 똑같이 검증한다. 외부 서비스로의 리다이렉트를 맹목적으로 따라가지 않는다.

---

마치며

웹 Top 10과 API Top 10을 나란히 보면 강조점이 다르다는 게 보인다.
웹은 인젝션·암호화·설정이 골고루 분포하는 반면, API는 인가(Authorization)에 위험이 집중돼 있다.
API1·API3·API5가 모두 "권한 검증을 빠뜨려서" 생기는 문제다.

이유는 단순하다. API는 화면(UI)이라는 방어막 없이 데이터에 직접 접근하는 통로이기 때문이다.
UI에서 버튼을 숨기는 것만으로는 아무 의미가 없다.
모든 요청에 대해 "이 사용자가 이 객체/기능에 권한이 있는가"를 서버에서 검증하는 것, 그게 API 보안의 9할이다.

웹과 API, 두 Top 10을 함께 알아두면 서비스 전체의 공격 표면이 보인다. 프론트와 백엔드가 분리된 요즘 구조에서는 둘 다 챙겨야 한다.

---

참고 출처

• OWASP API Security Top 10 2023 공식 — https://owasp.org/API-Security/editions/2023/en/0x11-t10/
• OWASP API Security Project — https://owasp.org/www-project-api-security/
• OWASP Cheat Sheet Series — https://cheatsheetseries.owasp.org/