OWASP API 보안 Top 10 개요 및 모범 사례

API의 기밀성, 무결성, 가용성을 확보하고 개인정보를 보호하며 사용자 및 이해 관계자의 신뢰를 유지하기 위해 무단 액세스, 조작 또는 노출로부터 데이터를 보호하려면 강력한 API 보안 조치가 필요합니다. API 보안의 모범 사례는 다음과 같습니다.

• 강력한 인증 및 권한부여 구현. 인증된 클라이언트가 특정 리소스에 액세스하거나 특정 작업을 수행하는 데 필요한 권한을 갖도록 적절한 권한 확인을 시행합니다. 세분화된 액세스 제어를 사용하여 민감한 API 엔드포인트 또는 데이터뿐만 아니라 관련 개체 및 기능에 대한 액세스를 제한합니다.
• 입력 및 출력 인코딩 검증. API 클라이언트에서 수신한 모든 입력을 검증하고 검사하여 인젝션 공격을 방지하고 출력을 적절히 인코딩하여 악성 스크립트의 실행을 방지합니다.
• 보안 통신 사용. API 클라이언트와 서버 간에 데이터를 전송하기 위한 보안 프로토콜을 사용하고 전송 중 및 저장 중인 민감한 정보를 암호화하여 데이터의 기밀성과 무결성을 확보합니다.
• 속도 제한 및 스로틀링 구현. 분산 서비스 거부(DDoS) 및 무차별 대입 공격과 같은 무단 액세스 시도 또는 과도한 사용을 방지하기 위해 API 클라이언트가 지정된 시간 내에 수행할 수 있는 요청 수에 제한을 적용합니다.
• 정기적인 보안 테스트 및 감사 수행. 정기적인 보안 평가, 침투 테스트, 코드 검토를 수행하여 API의 잠재적인 취약점을 식별 및 해결하고 보안 감사를 수행하여 취약점을 탐지하고 업계 표준 및 의무를 준수합니다. 이는 API와 기본 프레임워크와 라이브러리가 상호 의존적인 성격을 가지고 있으므로 특히 중요합니다.
• 스키마 및 프로토콜 준수. OpenAPI 사양을 사용하여 긍정적인 보안 모델을 자동으로 생성하여 적용함으로써 보안 정책의 일관성을 확보할 수 있습니다.
• API에 대한 동적 디스커버리 및 지속적인 평가. API 사용이 급증함에 따라 Shadow API를 포함한 고려되지 않거나 유지 관리되지 않는 API가 발생하고 있습니다. 보안 제어를 통해 제로 트러스트 및 최소 권한 액세스 패러다임을 사용하여 API를 지속적으로 인벤토리화하고 보호하여 타사 상호 의존성의 예기치 않은 위험을 완화해야 합니다.
• 포괄적인 위협 탐지. API는 공격, 구성 오류, 봇, 사기, 악용을 포함한 다양한 위협의 대상이 되므로 이러한 위협을 차단해야 합니다.

OWASP API 보안 Top 10 – 2023은 일반적인 API 보안 취약점에 대한 인식을 제고하고 개발자, 설계자, 관리자 등 API 개발 및 유지 관리와 관련된 담당자들이 API 보안에 대한 사전 예방적 접근 방식을 유지하도록 돕기 위해 만들어졌습니다.

2023년 OWASP API 보안 Top 10 위험은 다음과 같습니다.

1. 취약한 개체 수준 권한 부여. 이 보안 취약점은 애플리케이션이 개체 또는 데이터 수준에서 액세스 제어를 제대로 적용하지 못할 때 발생하며, 공격자가 권한 검사를 조작하거나 우회하여 애플리케이션 내 특정 개체 또는 데이터에 대한 무단 액세스를 허용할 수 있습니다. 이러한 상황은 권한 검사를 부적절하게 구현하거나, 적절한 유효성 검사를 수행하지 않거나, 접근 제어를 우회하는 등의 이유로 발생할 수 있습니다. 개체의 ID를 수신하고 해당 개체에 대한 작업을 수행하는 모든 API 엔드포인트는 개체 수준 권한 검사를 구현하여 로그인한 사용자가 요청된 개체에 대해 요청된 작업을 수행할 수 있는 권한을 가지고 있는지 확인해야 합니다.
2. 취약한 인증. API의 인증 메커니즘이 잘못 구현되어 공격자가 사용자 계정이나 민감한 데이터에 무단으로 액세스하거나 무단 작업을 수행할 수 있게 되는 경우가 많습니다. 이러한 상황은 일반적으로 인증 프로세스의 부적절한 구현 또는 구성, 취약한 비밀번호 정책, 세션 관리 결함 또는 인증 워크플로우의 기타 약점으로 인해 발생합니다.
3. 취약한 개체 속성 수준 권한 부여. 이 위협은 API가 객체 속성 수준에서 액세스 제어 및 권한 확인을 제대로 시행하지 못할 때 발생합니다. API 엔드포인트가 민감한 것으로 간주되어 사용자가 읽어서는 안되는 객체의 속성을 노출하는 경우 이러한 공격에 취약합니다. 이러한 공격을 과도한 데이터 노출이라고도 합니다. 사용자가 민감한 개체의 속성 값을 변경, 추가 또는 삭제할 수 있도록 허용하는 경우에도 API 엔드포인트는 이러한 공격에 취약합니다. 이러한 공격을 대량 할당이라고도 합니다.
4. 무제한 리소스 소비. 리소스 고갈이라고도 하는 이 공격은 API 구현의 약점을 악용하여 의도적으로 CPU, 메모리, 대역폭 또는 기타 시스템 리소스와 같은 리소스를 과도하게 소비하는 것을 포함합니다. 이러한 서비스 거부(DoS)는 API 또는 기본 시스템의 성능이나 가용성을 저하시키고 다운타임으로 이어질 수 있습니다.
5. 취약한 기능 수준 권한 부여. 이 위협은 API가 기능 또는 운영 수준에서 권한 검사를 제대로 시행하지 못하여 공격자가 권한이 없는 기능에 액세스할 수 있는 경우에 발생합니다. 모던 애플리케이션은 다양한 유형의 기능적 역할과 그룹을 정의하고 공격자가 조작할 수 있는 복잡한 사용자 계층 구조를 포함할 수 있기 때문에 적절한 권한 검사를 구현하기 어려울 수 있습니다.
6. 민감한 비즈니스 흐름에 대한 제한 없는 액세스. 이 공격은 API에 적절한 액세스 제어 또는 권한 검사를 수행하지 않을때 발생하며, 이를통해 공격자는 API가 지원하는 민감한 비즈니스 흐름에 대한 엑세스를 자동화할 수 있습니다. 이러한 비즈니스 흐름은 2차 시장에서 이윤을 적용하여 재판매할 수 있는 티켓이나 운동화와 같이 부가가치가 높고 재고율이 낮은 제품의 대량 구매를 지원할 수 있습니다. 공격자는 보통 정교한 자동화 툴킷을 사용하여 공격을 리툴링하고 타겟의 웹 앱이 자동화 방지 방어에 의해 적절하게 보호되는 경우 API에 적용되는 비즈니스 로직을 타겟팅하도록 전환할 수 있습니다.
7. 서버 측 요청 위조(SSRF). 이 취약점은 사용자가 제공한 URL을 수락하거나 외부 리소스에 대한 서버 측 요청을 수행하는 API 엔드포인트 중 취약한 엔드포인트를 공격자가 발견할 때 발생합니다. 공격자는 공격자가 타겟팅하려는 내부 리소스 또는 시스템의 URL을 지정하는 악의적인 요청을 만듭니다. 서버는 악의적인 의도를 모른 채 지정된 URL에 대한 서버 측 요청을 수행하여 민감한 정보 또는 서비스를 노출시킬 수 있습니다.
8. 보안 구성 오류. 공격자는 API에 대한 무단 액세스 권한을 얻기 위해 패치가 적용되지 않은 결함, 공통 엔드포인트, 안전하지 않은 기본 구성으로 실행되는 서비스 또는 보호되지 않은 파일 및 디렉토리를 찾으려고 시도합니다. 이 취약점은 네트워크에서 애플리케이션 수준에 이르기까지 API 스택의 모든 수준에서 적절한 보안 강화가 이루어지지 않았거나 클라우드 서비스에 잘못 구성된 권한이 있는 경우 발생할 수 있습니다. 구성 오류는 웹 앱과 API에 영향을 미치며, 아키텍처가 계속 분산되고 여러 멀티 클라우드 환경에 걸쳐 분산됨에 따라 위험이 증가하고 있습니다.
9. 부적절한 인벤토리 관리. API는 시간이 지남에 따라 변경 및 업데이트될 수 있지만 오래되거나 안전하지 않은 API 버전이 계속 실행되는 경우, 또는 오래된 엔드포인트에 패치가 적용되지 않은 상태로 운영되거나 약한 보안 요구 사항을 사용하는 경우 보안 침해의 위험이 증가할 수 있습니다. 적절한 인벤토리 관리가 이루어지지 않으면 사용 중인 버전, 오래된 버전 또는 지원이 종료된 버전, 해결된 취약점을 추적하기가 어렵습니다. Shadow 및 좀비 API는 심각한 위험을 초래할 수 있어 지속적인 검색과 자동화된 보호가 필요합니다.
10. 안전하지 않은 API의 사용. 개발자는 타사 API, 특히 유명 회사가 제공하는 API로부터 받은 데이터를 신뢰하는 경향이 있으며, 입력 유효성 검사 또는 전송 보안 측면에서 이러한 데이터에 대해 약한 보안 요구 사항을 적용하는 경향이 있습니다. 안전하지 않은 프로토콜을 통해 API에 액세스하거나 적절한 암호화 메커니즘을 사용하지 않아 도청, 데이터 가로채기, 민감한 정보에 대한 무단 액세스가 발생할 때도 안전하지 않은 소비가 발생할 수 있습니다.