API 공격에 무방비였던 이유, WAF가 놓친 것들

들어가며

몇 년 전만 해도 웹사이트 하나만 잘 지키면 됐습니다. 방화벽 하나 세워두고, 알려진 공격 패턴만 막아내면 대부분의 위협은 걸러졌으니까요. 그런데 요즘 개발팀 회의에 들어가 보면 이야기가 완전히 달라졌습니다. 마이크로서비스, 모바일 앱, 파트너사 연동, 서드파티 SDK까지 하나의 서비스가 수십 개의 API로 쪼개져 돌아가고 있습니다.

문제는 여기서 시작됩니다. 전통적인 웹 애플리케이션 방화벽, 흔히 WAF라고 부르는 이 방어선이 이런 구조 변화를 따라가지 못하고 있다는 점입니다. 실제로 보안 사고 사례를 살펴보면 방화벽은 멀쩡히 살아 있는데, 그 옆의 API 하나가 뚫려서 고객 데이터가 통째로 유출되는 경우가 늘고 있습니다. 오늘은 왜 이런 일이 벌어지는지, 그리고 가트너가 제시한 새로운 보안 개념인 WAAP가 무엇인지 차근차근 짚어보겠습니다.

• WAF(웹 애플리케이션 방화벽, Web Application Firewall)는 HTTP 트래픽을 검사하고 필터링하여 웹 애플리케이션을 악성 공격으로부터 보호하는 보안 솔루션입니다.

• WAAP(Web Application and API Protection)는 전통적인 웹 방화벽(WAF) 기능에 API 보안, 악성 봇(Bot) 완화, DDoS 방어 기능을 통합한 고도화된 클라우드 기반 웹 보안 솔루션입니다.

전통적인 WAF, 어디까지 방어할 수 있을까

WAF는 기본적으로 시그니처 기반으로 동작합니다. SQL 인젝션이나 크로스사이트 스크립팅처럼 이미 알려진 공격 패턴을 데이터베이스에 등록해두고, 들어오는 요청이 그 패턴과 일치하는지 검사하는 방식입니다. 이 방식은 정형화된 웹 페이지 요청을 막는 데는 꽤 효과적이었습니다.

하지만 여기에는 명확한 한계가 있습니다.

• 새로운 공격 기법이 등장하면 시그니처가 업데이트되기 전까지는 무방비 상태가 됩니다
• 정상적인 사용자 요청과 비정상적인 요청을 문맥 없이 패턴만으로 구분하다 보니 오탐과 미탐이 반복됩니다
• 요청 하나하나를 독립적으로 판단하기 때문에 여러 요청이 조합된 논리적 공격은 잡아내기 어렵습니다
• 애초에 HTML 기반 웹 페이지를 전제로 설계되어 JSON이나 GraphQL처럼 API 특유의 데이터 구조는 제대로 들여다보지 못합니다

즉 방화벽 자체가 고장 난 것이 아니라, 방화벽이 원래 상상하지 못했던 형태의 트래픽이 대부분을 차지하게 된 것이 진짜 문제입니다.

마이크로서비스와 API 중심 구조가 바꾼 공격 표면

과거의 웹 서비스는 사용자가 브라우저로 접속하는 단일한 진입점 하나만 지키면 됐습니다. 그런데 지금은 다릅니다. 모바일 앱, 웹 프런트엔드, 파트너 연동, 내부 서비스 간 통신까지 저마다 API 엔드포인트를 통해 데이터를 주고받습니다.

이렇게 되면 공격자 입장에서는 선택지가 훨씬 많아집니다. 정문을 두드리지 않고도 옆으로 난 작은 API 창문 중 하나를 찾아 들어가면 되는 셈입니다. 실제로 최근 수년간 발생한 대형 개인정보 유출 사고의 상당수가 웹사이트 자체가 아니라 백엔드 API의 인증 로직이나 권한 검증 허점에서 비롯되었습니다. 아래 그림은 전통적인 구조와 API 중심 구조가 얼마나 다른 방식으로 공격 표면을 만들어내는지를 비교한 것입니다.

전통적인 구조에서는 클라이언트가 WAF를 거쳐 하나의 애플리케이션에만 도달했다면, 지금은 클라이언트의 요청이 게이트웨이를 거쳐 수십 개의 마이크로서비스와 API로 흩어집니다. 지켜야 할 문이 하나에서 수십 개로 늘어난 셈입니다.

WAAP란 무엇인가, 가트너가 제시한 4가지 축

이런 변화 속에서 가트너는 기존의 WAF 개념을 확장한 WAAP, 즉 웹 애플리케이션 및 API 보호라는 개념을 제시했습니다. WAAP는 단일 제품이 아니라 네 가지 핵심 기능이 하나의 플랫폼 안에서 유기적으로 작동해야 한다는 관점에 가깝습니다.

1. WAF: 여전히 유효한 애플리케이션 계층 공격 필터링 기능
2. API 보안: API 스키마 검증, 인증 및 권한 오남용 탐지, 데이터 노출 방지
3. 봇 관리: 자동화된 스크래핑, 크리덴셜 스터핑, 매크로성 트래픽을 사람의 트래픽과 구분
4. DDoS 방어: 대규모 트래픽 폭주로 서비스 자체가 마비되는 상황을 막는 기능

이 네 가지가 따로 운영되면 각 솔루션 사이의 빈틈이 생기지만, 하나로 통합되면 하나의 요청이 여러 계층을 동시에 통과하며 종합적으로 판단됩니다. 아래 다이어그램은 이 네 가지 축이 WAAP라는 하나의 우산 아래 어떻게 배치되는지를 보여줍니다.

왜 API 보안이 현대 웹 방어의 핵심으로 떠올랐는가

네 가지 축 가운데서도 특히 API 보안이 주목받는 이유는 명확합니다. API는 단순히 데이터를 전달하는 통로가 아니라, 비즈니스 로직과 데이터베이스에 가장 가까이 맞닿아 있는 접점이기 때문입니다.

OWASP가 발표하는 API 보안 취약점 목록을 보면 상위권에는 항상 비슷한 유형이 등장합니다. 객체 단위 권한 검증이 빠져서 다른 사용자의 데이터를 그대로 조회할 수 있는 문제, 과도한 데이터를 응답에 담아 보내는 문제, 속도 제한이 없어 무한정 요청을 반복할 수 있는 문제 등입니다. 이런 취약점은 시그니처 매칭으로는 절대 잡히지 않습니다. 요청 자체는 문법적으로 완벽히 정상이기 때문입니다.

결국 API를 지키려면 요청 하나하나의 형태가 아니라, 그 요청이 누구의 것이고 어떤 데이터에 접근할 권한이 있는지를 이해해야 합니다. 이것이 바로 전통적인 방화벽 로직에서 API 보안이라는 별도의 계층이 필요해진 근본적인 이유입니다.

봇 관리와 DDoS 방어가 함께 필요한 이유

API가 늘어나면서 자동화된 봇의 활동 범위도 함께 넓어졌습니다. 로그인 API에 크리덴셜 스터핑을 시도하거나, 상품 조회 API를 통해 가격 정보를 대량으로 긁어가는 스크래핑 봇이 대표적입니다. 여기에 더해 API 엔드포인트 하나에 요청을 집중시켜 서비스 자체를 마비시키는 애플리케이션 계층 DDoS도 흔해졌습니다.

이 두 위협은 API 보안과 떼어놓고 생각하기 어렵습니다. 결국 봇 관리와 DDoS 방어까지 하나의 플랫폼에서 함께 다뤄야 실질적인 방어가 가능하다는 것이 WAAP가 강조하는 지점입니다.

결론, 단순한 방화벽에서 통합 플랫폼으로

정리하면 전통적인 WAF가 쓸모없어진 것은 아닙니다. 여전히 애플리케이션 계층의 기본적인 공격을 막아내는 데는 필요한 요소입니다. 다만 그것만으로는 지금의 API 중심 환경을 온전히 지킬 수 없다는 것이 명확해졌습니다.

앞으로 웹 서비스를 운영하거나 보안 전략을 세운다면, 방화벽 하나를 잘 고르는 것을 넘어 WAF, API 보안, 봇 관리, DDoS 방어가 하나의 시야 안에서 통합적으로 관리되는지를 먼저 점검해 보시길 권합니다. 공격자는 이미 가장 약한 고리를 찾아 움직이고 있습니다.

참고

가트너 WAAP 마켓 가이드, OWASP API Security Top 10 자료를 참고하여 작성하였습니다.