[Trouble Shooting] bingbot으로 인한 잘못된 API 요청 차단하기

📍 bingbot으로 인한 잘못된 API 요청 차단하기

문제 발견

해외 TNA 서비스내 DataDog 모니터링에서 /analytics 엔드포인트에 대한 500에러가 지속적으로 발생하고 있었습니다. 문제는 POST 메서드만 허용하는 엔드포인트에 GET 요청이 빈번하게 들어오고 있다는 점입니다.

원인 파악

애플리케이션 관점에서는 정상적인 사용자 flow에서는 절대 발생하지 않는 요청이었기에 크롤러에 의한 비정상 트래픽으로 짐작하고 DataDog내 User-Agent를 확인한 결과 Microsoft Bing의 검색 크롤러 봇이 원인이었습니다.

xxx.xxx.xx.xxx - - [12/Dec/2025:07:24:52 +0000] "GET /analytics HTTP/1.1" 500 90 "-" 
"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; 
+http://www.bing.com/bingbot.htm)"

 

프론트엔드 코드를 확인해보니 `/analytics` 엔드포인트는 명시적으로 POST 요청으로만 호출되고 있었습니다.

useEffect(() => {
  async function fetchPostProductAnalytics() {
    await postProductAnalytics(productId, {
      url: `${process.env.NEXT_PUBLIC_WEB_BASE_URL}/tna/products/${productId}`,
    })
  }

  fetchPostProductAnalytics()
}, [productId])

 

그렇다면 HTML 태그도 아니고, 링크로 노출된 적도 없는 이 엔드포인트에 왜 GET 요청이 발생했을까요?

왜 bingbot이 API를 호출했을까?

조사 과정에서 두 가지 중요한 사실을 확인했습니다.

 

1. bingbot은 JavaScript를 처리할 수 있다.

- bingbot은 단순히 HTML 링크만 수집하는 크롤러가 아니라, JavaScript 번들 파일을 다운로드하며 페이지 중요도나 환경에 따라 JavaScript를 실행해 렌더링할 수 있습니다. 이 과정에서 번들 내부에 포함된 API 경로가 노출되어 크롤링 대상이 된것으로 보입니다. 실제로 빌드된 JavaScript 번들 파일에서 /analytics 경로를 직접 확인할 수 있었습니다.

f = async (e, t) => await i.be.post("/foo/bar/baz".concat(e, "/analytics"), t);

 

이 과정에서 bingbot이 JS 번들 내 문자열을 정적으로 분석했거나, JS를 실행한 뒤 /analytics 경로를 수집한것으로 보입니다.

 

2. 크롤러는 HTTP Method의 의미를 고려하지 않는다.

크롤러는 API의 스펙을 이해하지 않기때문에, URL을 발견하면 기본적으로 GET 요청을 시도합니다. 그 결과 POST 전용 API임에도 GET 요청이 반복적으로 유입되었고 서버에 500 에러가 발생했죠.

대안 분석

1. ✅ 서버에서 405 METHOD_NOT_ALLOWED 처리

장점

• API 스펙 명확화 (POST만 허용)
• 에러 로그 가독성 향상

단점

• 요청이 백엔드까지 도달 (리소스 소모)
• 크롤러 요청 자체를 차단하지는 못함

2. 프론트 middleware에서 /analytics GET 요청 차단

장점

• 버티컬에서 빠른 대응 가능
• 불필요한 프록시 트래픽 감소

단점

• 예외케이스가 늘어날수록 미들웨어 로직 복잡도 증가

3. web/api gateway내 경로별 제한

장점

• 중앙 집중식 관리
• 여러 서비스에 일관된 정책 적용 가능

단점

• 다른 버티컬에서 동일 경로 사용간으성 존재
• 영향 범위 분석 필요

4. ✅ WAF(Web Application Firewall): 네트워크 레벨 차단

장점

• 가장 앞단에서 차단하여 리소스 최대 절약
• 프론트/백엔드 리소스 절약
• 인프라 레이어에서 확실한 방어

단점

• 인프라팀 협업 필요

최종 솔루션

백엔드(1번) + WAF(4번) 조합을 적용했습니다.

• WAF: bingbot을 네트워크 레벨에서 차단하여 비정상 요청을 근본적으로 차단
• 백엔드: 추후 동일한 패턴의 요청이 발생하더라도 405 응답으로 조기 식별 가능하도록 개선

기대 효과

1. DataDog내 동일 에러 로그 대폭 감소
2. 불필요한 트래픽 제거로 서버 리소스 절약
3. 네트워크 -> 애플리케이션 레벨의 다층 방어 구조로 안정성 확보

결론

이번 이슈를 해결하면서 크롤러가 단순히 HTML 링크만 수집하지 않고 JavaScript 번들 파일을 분석하거나 실행하여 URL을 추출한다는 점을 다시 한번 확인했습니다. 또한 버티컬내 문제로만 치부하지 않고, 네트워크 레벨부터 애플리케이션 레벨까지 여러 방어선을 구축하는 것이 운영환경에서는 훨씬 안정적인 접근이라는 점을 배울 수 있었습니다.

참고 자료

1. Bing Webmaster Guidelines - Bing 크롤러 동작 방식
2. bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! - Microsoft Bing Blogs