Rate Limit이 없는 API는 어떻게 공격받나 — 원리와 대응법

1. Rate Limit이 왜 중요한가

1) API는 생각보다 쉽게 반복 호출될 수 있습니다

RateLimit이 없는 API는 외부에서 짧은 시간 안에 여러 번 요청을 보내기 쉬워집니다. 로그인, 인증번호 확인, 비밀번호 재설정 같은 기능은 특히 반복 시도가 가능하기 때문에, 기본적인 API보안 장치가 없으면 공격에 더 노출되기 쉽습니다.

2) 많은 사람들이 검색하는 이유

개발자나 운영 담당자가 RateLimit, API공격원리, 브루트포스 같은 키워드를 찾는 이유는 대개 “정상 사용자는 불편하지 않으면서 공격은 막을 수 있는 방법이 무엇인지” 알고 싶기 때문입니다. 실제로 API는 웹페이지보다 자동화된 요청이 쉽기 때문에, 작은 허점이 반복 공격으로 이어지는 경우가 많습니다.

3) 이 글에서 다룰 내용

이 글에서는 RateLimit이 없는 API가 어떤 방식으로 공격받는지, API공격원리가 어떤 흐름으로 작동하는지, 그리고 API보안 측면에서 어떤 대응이 필요한지 차근차근 설명해보겠습니다. 단순히 “막아야 한다”가 아니라, 어떤 상황에서 위험해지는지까지 함께 살펴보는 방식입니다.

2. Rate Limit이 없는 API가 공격받는 방식

1) 가장 기본은 무차별 반복 요청입니다

RateLimit이 없으면 공격자는 같은 요청을 짧은 시간에 수백, 수천 번 반복할 수 있습니다. 예를 들어 로그인 API에 아이디와 비밀번호 조합을 바꿔가며 넣는 식의 브루트포스 공격이 대표적입니다.
이런 방식은 한 번의 요청은 실패해도, 시도 횟수가 많아질수록 성공 가능성이 점점 올라간다는 점에서 위험합니다.

2) 인증번호나 토큰 검증 API도 노려집니다

숫자 6자리 인증번호처럼 경우의 수가 제한된 API는 더 취약할 수 있습니다. RateLimit이 없다면 공격자는 인증번호를 빠르게 대입하며 정답을 찾으려 할 수 있습니다.
이 과정은 단순한 API공격원리처럼 보일 수 있지만, 실제 서비스에서는 계정 탈취나 본인인증 우회로 이어질 수 있어 주의가 필요합니다.

3) 자원 소모를 유도하는 공격도 가능합니다

공격의 목적이 꼭 계정 탈취만은 아닙니다. API 응답이 무겁거나 외부 시스템과 연동되는 구조라면, 대량 호출만으로도 서버 부하를 높일 수 있습니다. API보안이 약한 상태에서는 정상 사용자까지 느린 응답을 체감하게 될 수 있습니다.

3. 브루트포스와 API공격원리의 핵심

1) 브루트포스는 “가능한 조합을 끝까지 시도하는 방식”입니다

브루트포스는 말 그대로 가능한 입력값을 계속 대입해 정답을 찾는 방식입니다. API에서는 로그인 정보, 인증코드, 비밀번호 재설정 토큰, 초대 코드 등 다양한 입력값에 적용될 수 있습니다.
특히 RateLimit이 없거나 실패 횟수 제한이 없으면 공격 난도가 크게 낮아집니다.

2) 자동화가 쉬운 구조가 문제입니다

사람이 직접 몇 번 눌러보는 수준과 달리, 공격 도구는 요청 간격을 매우 짧게 설정할 수 있습니다. 이 때문에 API공격원리는 단순하지만 효과적일 수 있습니다.
예를 들어 실패 응답이 빠르고, 예외적인 차단 장치가 없다면 공격자는 정상 사용자처럼 보이게 요청을 보내면서도 내부적으로는 대량 시도를 진행할 수 있습니다.

3) 응답 차이를 통해 정보를 얻기도 합니다

브루트포스 외에도, 어떤 API는 응답 메시지나 상태 코드의 차이만으로도 공격 단서가 노출되곤 합니다.
예를 들어 “아이디가 존재하지 않음”과 “비밀번호가 틀림”을 구분해 알려주면, 공격자는 유효한 계정 목록을 추정할 수 있습니다. 이런 부분도 넓은 의미의 API보안 관점에서 점검해야 합니다.

4. Rate Limit이 없어도 생길 수 있는 추가 위험

1) 계정 열거 공격으로 이어질 수 있습니다

RateLimit이 없으면 로그인 API뿐 아니라 회원가입, 비밀번호 찾기, 이메일 확인 API도 위험해질 수 있습니다. 공격자는 여러 입력값을 넣어가며 계정 존재 여부를 확인하고, 이를 바탕으로 더 정교한 공격을 준비할 수 있습니다.

2) 내부 기능 노출을 확대할 수 있습니다

일부 API는 프론트엔드에서만 쓰는 것처럼 보여도, 실제로는 관리용 기능이나 테스트용 엔드포인트가 남아 있는 경우가 있습니다. 이런 경우 API공격원리는 더 단순해집니다.
공격자는 문서화되지 않은 호출을 반복하며 반응을 살펴보고, 민감한 기능이 열려 있는지 확인할 수 있습니다.

3) CORS나 인증 구조의 허점도 함께 드러납니다

RateLimit 문제가 있는 환경은 종종 다른 API보안 취약점도 같이 존재합니다. 예를 들어 쿠키 설정이 느슨하거나, CORS 정책이 과하게 열려 있거나, 토큰 검증이 약한 경우가 있습니다.
이런 요소가 겹치면 브루트포스만으로 끝나지 않고 세션 탈취나 권한 오용으로 이어질 수 있습니다.

5. 대응할 때 꼭 봐야 할 API보안 포인트

1) 요청 횟수 제한을 기능별로 나눠서 적용합니다

RateLimit은 전체 API에 일괄 적용하기보다, 로그인·인증번호 확인·비밀번호 재설정처럼 민감한 기능에 우선 적용하는 경우가 많습니다.
사용자 경험을 해치지 않으면서도 브루트포스를 억제하려면, IP 기준뿐 아니라 계정 기준이나 디바이스 기준 제한도 함께 고려할 수 있습니다.

2) 실패 횟수 기반 차단이 필요합니다

같은 계정에 대해 연속 실패가 발생하면 일정 시간 차단하거나 추가 인증을 요구하는 방식이 자주 쓰입니다.
이런 방식은 API공격원리에 대응하는 가장 실용적인 방법 중 하나입니다. 무조건 막기보다, 공격 징후가 보일 때만 강도를 높이는 식으로 운영할 수 있습니다.

3) 응답 메시지를 최대한 통일합니다

회원 존재 여부나 입력값 오류를 구분해서 알려주는 메시지는 공격자에게 힌트를 줄 수 있습니다.
API보안 관점에서는 상세 정보를 줄이기보다, 사용자에게 필요한 수준만 안내하는 편이 안전합니다. 예를 들어 “입력 정보를 확인해 주세요”처럼 통합된 메시지를 사용하는 식입니다.

4) 인증 외의 보조 방어도 함께 둡니다

RateLimit만으로 모든 공격을 막을 수는 없습니다. CAPTCHA, 이메일/문자 확인, 지연 응답, 위험 요청 탐지 같은 보조 장치가 함께 있으면 브루트포스 성공 확률을 더 낮출 수 있습니다.
특히 반복 요청이 의심되는 구간에서는 이러한 보완책이 꽤 효과적으로 작동합니다.

6. 실제 점검에서 자주 놓치는 부분

1) 개발 환경과 운영 환경 설정 차이

로컬에서는 잘 보이던 제한이 운영에서는 빠져 있는 경우가 있습니다. 배포 과정에서 RateLimit 설정이 누락되면, 테스트할 때는 멀쩡해 보여도 실서비스에서 문제가 생길 수 있습니다.

2) 모바일 앱 API도 따로 봐야 합니다

웹 프론트엔드만 점검하고 끝내는 경우가 있는데, 모바일 앱이 직접 호출하는 API는 별도 점검이 필요합니다. 공격자는 브라우저가 아니라 API 주소만 알고 있어도 접근을 시도할 수 있으므로, 전체적인 API보안 관점에서 봐야 합니다.

3) 민감한 기능만 집중 점검하는 습관이 필요합니다

모든 API를 똑같이 보호하는 것보다, 우선순위를 정하는 편이 현실적입니다. 로그인, 인증, 결제, 권한 변경, API 키 관련 기능은 특히 반복 시도에 취약하기 때문에 RateLimit 점검이 중요합니다.
이런 부분은 단순한 설정 확인만으로도 위험을 꽤 줄일 수 있습니다.

7. 정리: 언제 이런 점검이 유용한가

1) 이런 경우에 특히 도움이 됩니다

RateLimit이 없는지, 브루트포스에 취약한지, API공격원리상 반복 시도에 노출되는지 확인하고 싶을 때 이런 점검이 유용합니다. 특히 로그인, 인증번호, 비밀번호 재설정, 계정 조회처럼 반복 요청이 가능한 기능을 운영하는 경우라면 더 중요합니다.
또한 배포 전후로 기본적인 API보안 상태를 빠르게 확인하고 싶을 때도 점검이 도움이 됩니다.

2) 직접 전화 확인과 비교했을 때의 차이

보안 문제를 직접 하나씩 전화로 확인하는 방식은 시간이 많이 들고, 기술적인 항목까지 체계적으로 보기는 어렵습니다. 반면 URL 기반 점검은 실제 서비스에 노출된 기본 보안 상태를 빠르게 훑어보는 데 적합합니다.
물론 이것만으로 모든 취약점을 찾을 수 있는 것은 아니지만, RateLimit이나 보안 헤더, 노출 설정처럼 자주 놓치는 부분을 먼저 확인하는 데는 충분히 활용할 수 있습니다. 이런 기본 점검을 해두면 이후 프로젝트에서도 API보안 기준을 정리하는 데 도움이 됩니다.