모든 CISO가 API 보안에 대해 알아야 할 세 가지

F5 ADSP | 2025년 9월 30일

In the third episode of the F5 글로벌 CISO: 방어 전문가가 방어 전문가에게, 세 번째 에피소드에는 제가 가장 좋아하는 API 해커 중 한 명인 Corey Ball,이 함께했습니다. Corey는 지난 15년간 IT 및 사이버 보안 분야에서 활동해 왔으며, API 해킹에 관해 체계적으로 정리된 지식이 거의 없다는 사실을 깨닫고 말 그대로 그 분야의 책을 썼습니다. 그때 저희는 처음 만났습니다.

이 책은 Hacking APIs: Breaking Web Application Programming Interfaces,로, 웹 API 보안 테스트를 단기간에 익힐 수 있도록 안내합니다. Corey는 API 보안을 무료로 배울 수 있는 APIsec University,의 설립자이기도 하며, API 보안 및 웹 앱 침투 테스트를 수행하는 hAPI Labs,의 설립자 겸 CEO이기도 합니다.

지금 듣기

제 팟캐스트의 최신 에피소드를 확인해 보세요:

에피소드 3: “AI 시대의 API 보안”
에피소드 4: "간소화와 보안 강화: 최고경영진을 위한 핵심 사이버 보안 전략"

Corey는 분명 API 보안 전문가이기에, 저는 그에게 오늘의 핵심 질문을 던졌습니다. 모든 CISO가 API 보안에 관해 반드시 알아야 할 세 가지는 무엇일까요? 특히 공격자의 관점에서 API 보안을 바라봄으로써 방어자가 무엇을 배울 수 있다고 생각하는지 궁금했습니다.

팁 1: API 보안 테스트 도구를 테스트하세요

API는 세계에서 가장 가치 있는 자원 중 하나인 데이터를 전송하는 기반 기술입니다. Corey는 “하지만 이 데이터를 보호하기 위해 방화벽이나 웹 애플리케이션 방화벽 같은 여러 방어 계층을 구축하더라도, 인터넷에 노출된 API가 침해의 관문이 되는 경우가 많습니다.”라고 말했습니다. 인증을 요구하거나 권한 부여를 적용하지 않는 보안 취약 API가 있다면, 범죄 공격자가 이를 직접적인 침입 경로로 삼아 무단 요청을 보내고 다른 모든 보안 계층으로 보호되는 데이터를 훔칠 수 있습니다.

“방어 담당자들이 API 보안을 테스트하려면 적절한 도구와 접근 방식을 사용해야 한다는 점을 확실히 이해했으면 합니다.”라고 그는 말했다. 단순히 API에 자동화된 스캐너를 실행해 문제가 없다는 보고서를 받은 뒤 모든 것이 안전하다고 가정하는 것만으로는 충분하지 않다. 방어 담당자는 API 요청을 적극적으로 테스트하고 분석하여 실질적인 문제를 찾아내고 실제로 존재하는 보안 문제를 해결해야 한다.

테스터를 테스트하기. Corey에 따르면 테스트 역량과 도구를 검증하는 실용적인 방법 중 하나는 의도적으로 취약하게 만든 애플리케이션을 대상으로 연습하는 것입니다. 이러한 애플리케이션은 테스터가 일반적인 API 보안 문제를 직접 경험하고 재현하며 이해할 수 있도록 안전한 연습 대상으로 특별히 제작되었습니다. “예를 들어, OWASP API Security Project에서는 crAPI를 제공합니다. crAPI는 API 취약점을 의도적으로 다수 포함하고 있으며, API 보안을 교육하고 학습하며 실습할 수 있도록 제작된 훈련 도구입니다. 스캐너로 crAPI를 직접 검사해 어떤 결과가 나오는지 확인할 수 있습니다.” HSTS 헤더 누락이나 클릭재킹 방지 설정 오류처럼 표면적인 취약점만 발견된다면, 테스트 도구가 OWASP API Top 10에 포함된 것과 같은 더 심각한 API 취약점을 놓치고 있을 수 있습니다. Corey는 “이는 테스트 도구가 생각만큼 효과적이지 않을 수 있음을 보여줍니다”라고 말했습니다.

팁 2: WAF와 API 게이트웨이만으로는 API를 충분히 보호할 수 없습니다

Corey와 저는 기존의 기업용 취약점 도구와 관리 프로그램이 API에는 효과가 없다는 점도 논의했습니다. API는 기존 웹 앱을 노리는 공격과는 다른 유형의 공격에 취약하기 때문입니다. 예를 들어 객체 수준 권한 부여 취약점(BOLA)과 객체 속성 수준 권한 부여 취약점(BOPLA)은 API의 핵심 비즈니스 로직과 관련된 API 보안 결함입니다. 저는 Corey에게 기업이 WAF와 API 게이트웨이를 구축했다면 API 보호 측면에서 무엇이 부족한지 물었습니다.

그는 WAF와 API 게이트웨이가 애플리케이션 보안과 사용자 인증에 매우 중요하지만, 이것만으로는 API를 보호하기에 충분하지 않다고 말했다. API 보안에서 가장 큰 과제는 권한 부여다. 즉, 사용자가 자신의 데이터에만 접근하고 이를 조회, 수정 또는 삭제할 수 있도록 보장하는 것이다. 그는 “사용자 A가 사용자 A의 리소스와만 상호 작용할 수 있도록 해야 합니다. 사용자 B의 리소스를 변경하거나 읽거나 업데이트하거나 삭제할 수 없어야 합니다”라고 말했다. 이어 “API에서 권한 부여는 분명 까다로운 문제입니다. 세분화된 권한 부여 규칙이 마련되어 있지 않으면, 다른 사람의 리소스를 노리는 공격자의 요청도 정상적인 요청과 매우 비슷해 보일 수 있습니다”라고 덧붙였다.

권한 부여 제어는 여러 상호 보완적인 제어 수단을 결합하는 다계층 API 보안 접근 방식의 일부가 되어야 합니다. 그래야 한 계층이 실패하더라도 다른 계층이 계속 보호 기능을 제공할 수 있습니다.

팁 3: 생성형 AI를 보호하려면 추가적인 보안 조치가 필요합니다

조직이 생성형 AI와 AI 기반 앱에 대한 투자를 확대함에 따라, 이러한 기술이 API 공격 표면을 넓힌다는 점을 이해해야 합니다. 생성형 AI 애플리케이션은 근본부터 철저히 API로 이루어져 있기 때문입니다. 다시 말해, AI의 세계는 곧 API의 세계입니다. 생성형 AI 앱의 기반 구조는 API에 크게 의존하며, AI 시스템의 거의 모든 부분이 이러한 인터페이스를 통해 노출됩니다.

하지만 Corey와 제가 논의했듯이, API는 AI 앱과 아키텍처를 보호하는 데 따르는 과제의 일부일 뿐입니다. AI 엔진과 대규모 언어 모델(LLM) 역시 공격에 악용될 수 있는 다른 취약점을 노출합니다. 예를 들어 모델 컨텍스트 프로토콜(MCP)은 LLM을 외부 도구 및 서비스와 연결하기 위한 통합 프레임워크를 제공하는 오픈 소스 표준입니다. MCP는 AI를 앱에 통합할 때 많은 이점을 제공하지만, 동시에 중대한 보안 과제도 야기합니다. Corey는 “생성형 AI의 이면을 들여다보면 이미 수많은 API로 구성되어 있는데, 여기에 MCP까지 도입됩니다. MCP는 인증 및 권한 부여 제어가 취약해 보안에 취약한 경우가 많지만, 보안 대책도 빠르게 발전하고 있습니다.”라고 말했습니다.

MCP와 관련해 고려해야 할 또 다른 보안 문제는 프롬프트 인젝션 공격과 자연어 해킹입니다. “회사를 대표하는 AI 에이전트와 챗봇을 운영할 경우 이러한 공격은 비즈니스 위험으로 이어질 수 있습니다. 공격자는 AI 에이전트를 조작해 회사 이미지에 맞지 않는 부적절한 발언을 하게 하거나, 챗봇을 설득해 승인되지 않은 할인을 제공하게 할 수 있습니다.” 또한 조직은 챗봇이 회사의 법적 대리인으로 간주될 수 있으며, 챗봇의 발언과 행동에 대해 회사가 법적 책임을 질 수 있다는 점을 이해해야 합니다. 기업은 신중해야 합니다. AI 앱이 제공하는 비즈니스 기회를 놓쳐서는 안 되지만, AI 앱과 챗봇이 정확한 데이터로 학습되고 프롬프트 인젝션으로부터 안전하게 보호되도록 충분한 실사를 거쳐야 합니다.

Corey와 근황을 나누는 것은 언제나 즐거운 일이며, 공격자의 관점에서 보안을 바라봄으로써 방어자가 무엇을 배울 수 있는지 함께 논의해 주신 데 감사드립니다. 방어자로서 우리의 방어 전략은 공격에 대한 이해를 바탕으로 수립되어야 합니다. 따라서 공격이 어떻게 이루어지고 공격자들이 무엇을 노리는지 모두가 이해해야만, 한정된 자원을 기업이나 정부 부처, 기관에 적합한 다계층 방어 체계에 효과적으로 배분할 수 있습니다.