OWASP API Security Top 10:2023: 객체·속성·기능 인가와 자원 제한

1장 개념과 보호 목표#

API 보안은 사용자가 로그인했는지 확인하는 것만으로 완성되지 않습니다. 대상 객체, 수정 가능한 속성, 호출 가능한 기능을 요청마다 검증해야 합니다. OWASP API Security Top 10:2023은 이러한 인가 실패와 자원·운영 위험을 정리한 목록입니다.

2장 원리와 구분#

BOLA는 타인 객체 접근, 속성 수준 인가 실패는 불필요한 데이터 노출·임의 필드 수정, 기능 수준 인가 실패는 관리자 기능 등의 호출 문제입니다. UUID를 쓰면 추측을 어렵게 할 수 있지만 소유권 검증을 대신하지 않습니다. 목록은 이외에도 인증 실패, 무제한 자원 소비, 민감 업무 흐름 남용, SSRF, 설정 오류, API 목록 관리 실패, 외부 API의 안전하지 않은 소비를 다룹니다.

3장 비교와 판단 기준#

인가 계층	질문	예시
객체	이 객체에 접근 가능한가?	타인 주문 조회 차단
속성	이 필드를 보거나 바꿀 수 있는가?	가격·권한 필드 수정 차단
기능	이 기능을 호출할 수 있는가?	관리자 일괄 내보내기 제한
자원·업무	이 규모와 반복이 허용되는가?	페이지·거래·호출 한도

4장 로그인 이후의 세 가지 인가#

객체 인가는 이 주문·문서에 접근할 수 있는지, 속성 인가는 어느 필드를 읽거나 바꿀 수 있는지, 기능 인가는 이 API 작업을 호출할 수 있는지를 확인합니다. 하나의 역할 검사만으로 세 조건이 모두 충족되지는 않습니다. 실제 자원과 요청의 업무 의미를 연결해야 합니다.

일반 사용자의 주문 요청
객체: 자기 조직·소유 주문인가?
속성: 가격·소유자·권한을 임의 수정하는가?
기능: 관리자 일괄 처리 기능인가?

5장 BOLA에서 ID를 숨기는 것만으로 부족하다#

UUID나 긴 식별자는 추측을 어렵게 할 수 있지만 로그·공유·응답에서 알려질 수 있습니다. ID를 안다는 사실과 자원에 대한 권한을 구분합니다. 서버 저장소의 실제 소유·조직과 신뢰한 현재 사용자를 비교해야 합니다.

조회뿐 아니라 수정·삭제·다운로드·배치에도 적용합니다. 목록의 필터가 맞아도 단건 엔드포인트에서 같은 검증이 빠질 수 있습니다.

6장 BOPLA와 입력·응답 필드#

요청 본문을 객체에 그대로 매핑하면 owner·role·price 같은 서버 결정 필드가 바뀔 수 있습니다. 허용 입력 DTO·필드 목록과 변경 정책을 사용합니다. 응답의 내부 상태·개인정보·관리 필드도 필요한 역할에만 제공합니다.

flowchart LR
 R["요청 JSON"] --> D["허용 입력 필드 선택"]
 D --> V["기능·객체·속성 인가"]
 V --> S["서버 결정 값과 상태 변경"]
 S --> O["권한에 맞는 응답 필드"]

7장 BFLA와 관리자 기능#

관리 경로를 문서에서 숨기거나 버튼을 제거해도 직접 요청을 보낼 수 있습니다. 서버는 기능 권한을 검사하고 경로·메서드·버전의 우회를 시험해야 합니다. 관리자라고 해도 모든 조직의 객체를 허용할지 정책으로 정합니다.

일괄 내보내기·사용자 관리·배치 작업은 일반 조회와 영향이 다릅니다. 강한 인증·승인·기록·한도를 해당 기능의 위험에 맞춰 적용합니다.

8장 자원 소비와 업무 남용#

페이지 크기·요청 크기·동시 작업·DB 비용·외부 호출·금전 비용을 제한합니다. 예약·쿠폰·계정 생성처럼 업무 반복 자체가 피해가 되는 흐름도 별도 한도가 필요합니다. 인증된 사용자라는 이유로 자원과 업무 효과를 무제한 허용하지 않습니다.

측정에서는 요청 수와 업무 성공률·연산·비용을 함께 봅니다. IP만 제한하면 공유망 정상 사용자가 영향을 받을 수 있어 계정·조직·토큰·행위 조건을 결합합니다.

9장 SSRF에서 최종 목적지를 검증한다#

URL 미리보기·웹훅·외부 이미지 가져오기처럼 서버가 외부 주소에 연결하는 기능은 신뢰 경계입니다. 스킴·호스트·해석된 주소·포트·리다이렉트·재시도와 최종 연결을 정책으로 제한합니다. 문자열 접두어 하나로 전체 경로가 검증되었다고 보지 않습니다.

내부·관리·메타데이터 주소와 불필요한 외부 경로의 접근을 제한합니다. 사용한 네트워크 라이브러리와 배포망에서 실제 우회·해석의 조건을 확인해야 합니다.

10장 외부 API 응답도 데이터다#

계약한 공급자의 응답이라도 형식·길이·상태·신뢰도를 검증합니다. HTML·명령·질의에 그대로 넣거나 과도한 응답·재시도를 허용하면 공급자 문제와 입력이 서비스에 영향을 줄 수 있습니다. 타임아웃·전체 비용·실패·대체 동작을 정합니다.

flowchart TB
 U["사용자가 지정한 외부 작업"] --> P["대상·권한·한도 검증"]
 P --> C["제한된 연결"]
 C --> R["응답 형식·크기·상태 검증"]
 R --> B["업무에 맞는 안전한 처리"]

11장 API 인벤토리와 폐기#

경로·버전·소유자·인증·데이터·외부 의존성·폐기일을 기록합니다. 문서에서 지웠어도 구버전이 실제로 응답하는지 확인합니다. 테스트·모바일·협력사 API도 같은 목록에 들어가야 합니다.

키 회수·클라이언트 전환·경로 차단·모니터링을 연결해 폐기를 완료합니다. 구형 API가 새 정책을 우회하는 경로로 남지 않게 실제 요청으로 검증합니다.

12장 조직 경계를 시험하는 표#

사용자와 요청	기대 결과
A 조직의 사용자가 A의 허용 주문 조회	성공
같은 사용자가 B의 주문 ID 요청	거부
일반 사용자가 가격·소유자 필드 수정	거부
일반 사용자가 관리자 내보내기 호출	거부
허용 사용자라도 자원 상한 초과	정책에 따른 제한

기능·객체·속성·자원·외부 경계를 각각 시험해야 합니다. 게이트웨이에 인증을 넣었다는 사실만으로 서버의 모든 업무 인가가 끝난 것은 아닙니다.

13장 적용 사례와 운영 방법#

주문 API는 주문 소유권을 확인하고 상태·가격처럼 사용자가 바꾸면 안 되는 필드를 입력 DTO에서 제외합니다. 외부 API 응답도 검증하며 타임아웃·크기·리다이렉트·재시도 한도를 둡니다. 구버전 API와 문서에 없는 엔드포인트까지 인벤토리에 포함해야 합니다.

14장 API 요청의 권한·자원 검증#

flowchart LR
 R["요청"] --> A["신원 확인"]
 A --> F["기능 권한"]
 F --> O["객체 소유권"]
 O --> P["속성 허용 목록"]
 P --> L["업무·자원 한도"]
 L --> E["실행·기록"]

15장 인가 실패 세 가지를 한 요청에서 나눠 시험한다#

주문 수정 요청에서는 주문 자체에 접근 가능한지(BOLA), price·owner·role 같은 속성을 바꿀 수 있는지(BOPLA), 해당 수정 기능을 호출할 수 있는지(BFLA)를 나눕니다. 요청 DTO에 허용 필드만 넣고 자원 소유권·조직 경계와 기능 권한을 서버에서 판단합니다. 응답 필드도 역할에 맞게 제한해야 합니다.

인증된 사용자라도 대량 내보내기, 반복 예약, 비싼 이미지 변환을 남용할 수 있습니다. 요청 수 외에 페이지 크기·동시성·총 연산량·외부 API 비용·업무 횟수의 상한을 둡니다. 합법적인 계정의 업무 남용은 로그인 실패 경보만으로 찾기 어렵습니다.

16장 외부 URL 호출과 오래된 API를 함께 점검하기#

URL 미리보기나 웹훅 등록은 SSRF의 주요 검토 지점입니다. 허용 대상, DNS 해석 결과, 내부·메타데이터 주소, 리다이렉트와 재시도 경로를 정책과 라이브러리 수준에서 제한합니다. 문자열 접두어 검사 하나로 최종 목적지까지 검증했다고 판단해서는 안 됩니다.

배포 인벤토리에는 버전·소유자·인증 방식·폐기일을 남깁니다. 문서에서 제거한 구버전이 실제로 응답하는지 확인하고, 외부 API 응답도 길이·형식·신뢰도를 검증합니다. 계약한 공급자의 응답이라는 이유로 실행 코드나 DB 입력을 무검증으로 받아들이면 안 됩니다.

17장 적용 전 확인할 사항#

객체·속성·기능 인가를 각각 테스트한다
요청 크기·페이지·동시성·업무 한도를 제한한다
외부 URL 호출과 API 버전 폐기를 관리한다

18장 자주 묻는 질문#

추측하기 어려운 ID면 BOLA를 막을 수 있나요?#

ID가 로그나 공유 링크에서 노출될 수 있습니다. 대상 자원과 현재 사용자의 관계를 서버에서 검증해야 합니다.

관리자 API를 숨겨 두면 BFLA를 방어할 수 있나요?#

경로를 알아내는 방법은 다양합니다. 호출할 때마다 서버에서 기능 권한을 검사하고 일반 계정의 직접 호출을 시험해야 합니다.

요청 한도가 같으면 API별 위험도 같은가요?#

요청당 비용과 업무 효과가 다릅니다. 조회·변환·결제 등 기능의 비용과 남용 영향을 기준으로 한도를 설계해야 합니다.