모든 CISO가 꼭 알아야 할 API 보안 세 가지

F5 글로벌 CISO 3회차에서는: 수비수에 의한 수비수 모임에는 제가 가장 좋아하는 API 해커 중 한 명인 코리 볼이 참여했습니다. 코리는 지난 15년 동안 IT와 사이버 보안 분야에서 활동해 왔으며, 해당 주제에 대한 수집된 지식이 별로 없다는 것을 알게 되어 API 해킹에 관한 책을 썼습니다. 바로 그때 우리가 처음 만났습니다.

이 책은 Hacking APIs: 웹 애플리케이션 프로그래밍 인터페이스 공격 방법을 다루며 웹 API 보안 테스트를 빠르게 배울 수 있습니다. 코리는 API 보안 무료 학습 플랫폼인 APIsec University를 공동 설립했으며, API 보안 및 웹 앱 침투 테스트를 전문으로 하는 hAPI Labs의 창립자 겸 CEO입니다.

Corey는 API 보안 분야의 전문가입니다. 그래서 오늘의 질문을 그에게 직접 물어보았습니다: 모든 CISO가 API 보안에서 반드시 알아야 할 세 가지는 무엇일까요? 특히, 공격자의 시각에서 API 보안을 분석하면 방어자들이 어떤 인사이트를 얻을 수 있는지 듣고 싶었습니다.

API는 세계에서 가장 귀중한 자원 중 하나인 데이터를 전송하는 핵심 기술입니다. 코리가 말하길, “우리가 방화벽이나 웹 애플리케이션 방화벽 같은 여러 방어층으로 데이터를 보호해도, 인터넷에 노출된 API는 종종 해킹의 관문이 될 수 있습니다.” 인증이나 권한 검증을 하지 않는 보안 취약한 API가 있다면, 공격자는 이를 통해 직접 침입해 허가받지 않은 요청을 실행하고, 다른 방어층으로 보호된 데이터를 훔칠 수 있습니다.

“방어자들이 API 보안을 테스트할 때 올바른 도구와 방법을 꼭 사용해야 한다는 점을 반드시 알리려 합니다.”라고 말했습니다. 단순히 자동 스캐너를 API에 적용해 깨끗한 보고서를 받고 모든 것이 안전하다고 생각하는 것으로는 충분하지 않습니다. 직접 API 요청을 활발히 테스트하고 분석해 실제 문제를 발견하고 모든 보안 문제를 신속히 해결해야 합니다.

테스터의 역량을 점검하세요. 코리는 테스트 기술과 도구를 검증하는 효과적인 방법 중 하나로, 의도적으로 취약한 애플리케이션을 대상으로 연습할 것을 권합니다. 이런 애플리케이션은 안전하게 제작된 실습용 대상이며, 테스터가 흔한 API 보안 문제를 체험하고 재현하며 이해할 수 있게 도와줍니다. 예를 들어 OWASP API 보안 프로젝트에서는 crAPI라는 훈련 도구를 제공합니다. 이 도구는 API 취약점을 일부러 포함시켜 API 보안을 교육하고 배우며 연습하는 데 최적화되어 있습니다. 스캐너를 바로 crAPI에 대고 검사 결과를 확인해 보세요. 만약 HSTS 헤더 누락이나 잘못 설정된 클릭잭 방지 같은 단순한 취약점만 발견된다면, 테스트 도구가 OWASP API Top 10에 소개된 더 심각한 API 취약점은 놓치고 있을 가능성이 큽니다.  코리는 “이렇게 되면 도구가 생각만큼 효과적이지 않다는 것을 알 수 있습니다.”라고 강조했습니다.

코리와 저는 기존 엔터프라이즈 취약점 도구와 관리 프로그램이 API에는 효과적이지 않다는 점도 이야기했습니다. API는 기존 웹 애플리케이션과 다른 유형의 공격에 노출되기 때문입니다. 예를 들어, 객체 수준 권한 부여 결함(BOLA)과 객체 속성 수준 권한 부여 결함(BOPLA)은 API 핵심 비즈니스 로직과 관련된 보안 취약점입니다. 코리에게 WAF와 API 게이트웨이를 도입한 기업이 API 보호 측면에서 어떤 부분을 놓치고 있는지 물었습니다.

WAF와 API 게이트웨이는 애플리케이션 보안과 사용자 인증에 매우 중요하지만, API를 보호하는 데 단독으로는 충분하지 않습니다. API 보안에서 가장 큰 과제는 권한 부여입니다. 사용자가 자신에게 해당하는 데이터만 접근하고, 확인하거나 수정, 삭제할 수 있도록 해야 합니다. “사용자 A가 오직 사용자 A의 자원과만 상호작용할 수 있어야 합니다. 사용자 B의 자원을 변경하거나 열람, 업데이트, 삭제할 수 없어야 합니다.” “API 권한 부여는 확실히 까다롭습니다. 범죄자가 다른 사람의 자원을 요청해도, 세밀한 권한 규칙이 없으면 합법적인 요청처럼 보이기 쉽습니다.”

권한 제어를 여러 보완적 계층과 결합한 다중 방어 체계에 포함시켜 한 계층이 실패해도 다른 계층이 계속해서 보호 기능을 수행하도록 해야 합니다.

조직이 생성 AI와 AI 기반 앱에 점점 더 많이 투자할수록 이러한 기술이 API 공격 노출 면을 넓힌다는 점을 이해해야 합니다. 그 이유는 생성 AI 애플리케이션이 API로 완전히 구성되어 있기 때문입니다. 즉, AI 세상은 API 세상이며, 생성 AI 앱의 기반 구조가 API에 크게 의존하고 AI 시스템의 거의 모든 부분이 이 인터페이스를 통해 노출됩니다.

하지만 Corey와 내가 논의했듯, API는 AI 앱과 아키텍처 보안 과제의 일부일 뿐입니다. AI 엔진과 대규모 언어 모델(LLM)도 또 다른 취약점을 드러냅니다. 예를 들어, Model Context Protocol(MCP)은 LLM을 외부 툴과 서비스에 연결하는 통합 프레임워크를 제공하는 오픈소스 표준입니다. MCP는 AI를 앱에 통합할 때 많은 이점을 주지만, 동시에 중대한 보안 문제도 동반합니다. Corey가 말하길, “생성형 AI 내부를 살펴보면 이미 여러 API가 존재하며, 여기에 인증과 권한 부여가 약한 MCP가 추가되는데—물론 보안 체계도 빠르게 발전하고 있습니다.”

MCP의 또 다른 보안 고려사항은 프롬프트 인젝션 공격과 자연어 해킹입니다. “AI 에이전트와 챗봇이 회사를 대표할 때 비즈니스 위험이 발생할 수 있습니다. 공격자는 AI 에이전트를 조작해 회사 이미지를 손상시키는 발언을 하게 하거나, 챗봇을 설득해 무단 할인을 제공하게 만들 수 있습니다.” 조직은 챗봇이 회사의 법적 대리인으로 인정되어 진술과 행동에 법적 책임을 질 수 있음을 이해해야 합니다. 기업은 AI 애플리케이션이 제공하는 비즈니스 기회를 놓치지 않도록 주의를 기울이면서도, AI 앱과 챗봇이 정확한 데이터로 교육되고 프롬프트 인젝션으로부터 안전한지 반드시 확인해야 합니다.

Corey와 대화를 나누는 것은 항상 반갑습니다. 공격자의 관점에서 보안을 바라보며 방어자가 무엇을 배울 수 있는지 함께 이야기할 기회를 주셔서 감사드립니다. 방어자로서 우리는 공격 방식을 충분히 이해해야만 효과적인 방어를 세울 수 있습니다. 공격자가 무엇을 노리는지 알면, 제한된 자원을 기업이나 부처, 기관에 알맞은 다층 방어 전략에 현명하게 집중할 수 있습니다.