API 보안 취약점은 한 겹만 봐서는 놓치기 쉽습니다

API가 정상적으로 응답하고 눈에 띄는 오류도 없다면 안전한 걸까요?

그렇게 판단하기는 어렵습니다.

API는 서비스의 데이터와 기능을 직접 연결합니다. 겉으로는 정상적인 요청처럼 보여도 그 안에서는 다른 사용자의 데이터가 반환되거나, 일반 사용자에게 관리 기능이 열리거나, 내부 구조와 설정 정보가 예상보다 많이 드러날 수 있습니다.

API 보안 취약점은 한 가지 화면이나 한 번의 응답만 보고 판단하기 어렵습니다.

경로, 파라미터, 권한, 설정, 통신 방식과 실제 응답을 여러 층에서 함께 봐야 합니다.

먼저 무엇이 외부에 보이는지 확인해야 합니다

API 점검은 외부에서 확인되는 접점을 파악하는 일부터 시작합니다.

운영 중인 호스트와 API 경로, 요청 메서드와 파라미터를 확인하고, 프런트엔드 JavaScript 번들과 라우터, Swagger·OpenAPI 문서, GraphQL 스키마, 오류 응답과 관리용 경로에서 추가 후보를 찾아야 합니다.

오래된 API 버전이나 테스트 엔드포인트가 남아 있을 수도 있고, 담당자가 관리 대상이라고 인지하지 못한 경로가 실제 서비스처럼 응답할 수도 있습니다.

그러나 경로를 많이 찾았다고 점검이 끝나는 것은 아닙니다.

발견한 API가 어떤 조건에서 어떤 데이터와 기능을 제공하는지 더 면밀히 확인해야 합니다.

권한 검사는 객체와 기능을 나누어 봐야 합니다

API에서 특히 주의해야 할 부분은 인증 이후의 인가입니다.

로그인에 성공했더라도 사용자가 모든 데이터와 기능에 접근할 수 있는 것은 아닙니다.

주문번호나 사용자 식별자를 바꿨을 때 다른 사람의 데이터가 반환되는지, 일반 사용자가 관리자용 API를 호출해 실제 데이터나 기능에 접근할 수 있는지 확인해야 합니다.

BOLA는 요청한 사용자가 해당 객체를 조회·변경·삭제할 권한이 있는지를 제대로 검증하지 않을 때 발생할 수 있습니다. BFLA는 사용자 역할에 허용되지 않은 관리 기능이나 내부 기능이 실행될 때 문제가 됩니다.

경로 이름을 숨기거나 화면에서 메뉴를 감추는 것은 권한 검사를 대신하지 못합니다. 서버가 요청마다 사용자·대상 객체·기능의 관계를 확인해야 합니다.

외부에 드러난 정보가 공격의 단서가 될 수 있습니다

API 자체뿐 아니라 주변에 노출된 파일과 관리 정보도 함께 살펴야 합니다.

소스맵에는 원본 코드의 일부와 파일 경로, 주석, 내부 API 구조가 포함될 수 있습니다. 관리 엔드포인트와 오류 응답에는 환경 설정이나 프레임워크 정보가 나타날 수 있고, 클라이언트 번들에는 외부에 공개하면 안 되는 토큰이나 내부 경로가 남아 있을 수 있습니다.

백업 파일, 공개 스토리지, 내부 작업 문서가 웹 경로에 방치돼 있다면 API 구조와 데이터 흐름을 이해하는 단서가 될 수도 있습니다.

다만 외부에서 보인다는 사실만으로 모두 취약점이라고 단정해서는 안 됩니다.

공개 목적이 있는 문서인지, 실제 비밀정보가 포함됐는지, 인증 없이 접근 가능한지, 노출된 정보로 어떤 행위가 가능한지를 함께 확인해야 합니다.

설정과 통신 방식도 실제 동작으로 확인해야 합니다

CORS, HTTP 메서드, Host와 X-Forwarded-Host 처리, WebSocket, 보안 응답 헤더도 API 보안 상태를 판단하는 중요한 단서입니다.

하지만 특정 헤더가 보이거나 메서드가 열려 있다는 이유만으로 취약점이 확정되는 것은 아닙니다.

허용되지 않은 Origin에서 인증된 데이터에 접근할 수 있는지, 메서드를 바꿨을 때 인증·인가 검사를 우회하거나 의도하지 않은 상태 변경이 가능한지, 호스트 헤더가 링크 생성과 라우팅 판단을 왜곡하는지처럼 실제 영향을 확인해야 합니다.

암호화되지 않았거나 인증 절차가 부족한 WebSocket 채널, 내부 클래스명과 쿼리 정보가 드러나는 상세 오류 응답도 같은 방식으로 살펴야 합니다.

면밀한 점검은 여러 신호를 연결해 판단하는 일입니다

API 보안은 취약점 이름을 많이 붙이는 일이 아닙니다.

다음 질문에 근거를 갖고 답할 수 있어야 합니다.

- 외부에서 어떤 API와 관리 경로가 보이는가
- 각 요청은 어떤 인증과 권한 조건을 거치는가
- 다른 사용자의 데이터나 허용되지 않은 기능에 접근할 수 있는가
- 명세·소스·설정·오류 응답에서 민감정보가 드러나는가
- 통신 정책과 허용 메서드가 의도한 보안 기준과 일치하는가
- 문제가 발견됐다면 조치 후 실제 응답이 달라졌는가

하나의 신호만 떼어 보면 정상처럼 보일 수 있습니다. 여러 층의 조건과 응답을 연결해서 봐야 실제 위험을 놓치지 않을 수 있습니다.

점검 결과에는 발견한 경로와 요청 조건, 응답의 차이, 판단 근거가 함께 남아야 합니다. 그래야 담당자가 문제를 이해하고 조치한 뒤 같은 조건으로 다시 확인할 수 있습니다.

AEGISonar는 외부 공격표면의 발견과 Application Layer 점검, 취약점 설명과 조치 가이드, 재점검을 하나의 운영 흐름으로 연결합니다.

API 보안 역시 겉으로 드러난 주소만 모으는 데서 끝나지 않아야 합니다. 권한·설정·노출 정보·통신 방식과 실제 응답을 세밀하게 확인하고, 발견 근거가 조치와 재점검으로 이어져야 합니다.

API 보안 취약점은 한 겹만 봐서는 놓치기 쉽습니다.

중요한 것은 더 많은 경보가 아니라, 서로 다른 신호를 면밀하게 확인해 실제 위험을 구분하는 것입니다.

AEGISonar 살펴보기
https://aegisonar.com/

참고 기준
OWASP API Security Top 10 2023
https://owasp.org/www-project-api-security/