Rate Limit은 단위 시간 동안 클라이언트가 보낼 수 있는 요청 수를 제한해 brute force·API 남용·자원 고갈을 막는 트래픽 제어 메커니즘이다.
AI 코딩 도구가 만든 코드에서 가장 자주 누락되며, 누락 시 인증 우회·데이터 탈취·서비스 마비로 직결된다.
이 글은 자주 발생하는 실수 패턴, 표준 구현 코드, 30초 자가진단, 24시간 패치 순서를 정리했다.
한눈에 보는 핵심
Q. IP 기반 Rate Limit만으로 충분한가요? A. 충분하지 않습니다. 분산 IP·프록시·VPN으로 우회 가능하며, IP + 디바이스 ID + 계정 ID 조합이 표준입니다. Q. X-Forwarded-For는 신뢰할 수 있나요? A. 사용자가 임의로 위조할 수 있습니다. 신뢰 가능한 프록시 체인에서만 사용하고, 최외곽 IP만 화이트리스트에서 읽어야 합니다. Q. 토큰 버킷과 슬라이딩 윈도우 중 어떤 게 좋나요? A. 토큰 버킷이 버스트 허용에 유리하고, 슬라이딩 윈도우가 정확도가 높습니다. API 종류에 따라 혼합 사용이 권장됩니다.자주 발생하는 실수 패턴
| # | 패턴 | 위험도 |
|---|---|---|
| 1 | IP만으로 식별 — 분산 IP로 즉시 우회 | 치명 |
| 2 | X-Forwarded-For 무검증 사용 — 클라이언트 위조 가능 | 치명 |
| 3 | Redis 미사용 — 단일 서버 메모리에 카운트, 다중 워커 시 우회 | 높음 |
| 4 | CDN/캐시 앞단에서 카운트 — 캐시 적중 시 백엔드 카운트 누락 | 높음 |
| 5 | Rate Limit 응답이 200 — 클라이언트가 우회 시도 인지 | 중간 |
표준 구현 코드
from django.core.cache import cache
from rest_framework.throttling import BaseThrottle
import hashlib
class CompositeThrottle(BaseThrottle):
"""IP + 디바이스 ID + 계정 ID 결합 토큰 버킷"""
rate = 60 # per minute
def get_ident(self, request):
# 신뢰 가능한 프록시 체인 최외곽만 사용
ip = request.META.get('HTTP_X_FORWARDED_FOR', '').split(',')[0].strip() \
or request.META.get('REMOTE_ADDR', '')
device = request.headers.get('X-Device-ID', '')
user = request.user.id if request.user.is_authenticated else 'anon'
# 다중 식별자 결합 — 단일 우회 차단
return hashlib.sha256(f'{ip}|{device}|{user}'.encode()).hexdigest()
def allow_request(self, request, view):
key = f'rl:{self.get_ident(request)}:{view.__class__.__name__}'
count = cache.get(key, 0)
if count >= self.rate:
return False
cache.set(key, count + 1, 60) # TTL 60s
return True
def wait(self):
return 60
핵심 4요소를 모두 충족해야 결함이 사라진다.
AI 도구는 동작 코드만 출력하므로 보안 분기는 별도로 강제해야 한다.
미들웨어/데코레이터로 모든 경로에 일괄 적용이 표준이다.
30초 자가진단
# 1. 동일 endpoint 100회 요청 — 차단 확인
for i in $(seq 1 100); do curl -o /dev/null -s -w "%{http_code}\n" https://api.yourdomain.com/v1/login -d 'u=x&p=y'; done | sort | uniq -c
# 2. X-Forwarded-For 위조 — 매 요청 다른 IP
for i in $(seq 1 100); do curl -s -H "X-Forwarded-For: 1.2.3.$i" https://api.yourdomain.com/v1/login; done
# 결과가 모두 200이면 우회 결함
위 시그널이 발견되면 결함이다. OWASP A04: Insecure Design 참조.
24시간 패치 절차
| 순위 | 조치 |
|---|---|
| 1 | Redis 기반 분산 카운터로 다중 워커 통합 |
| 2 | IP + 디바이스 ID + 계정 ID 결합 키 사용 |
| 3 | 신뢰 프록시 체인 외 X-Forwarded-For 무시 |
| 4 | Rate Limit 응답을 429 Too Many Requests로 명시 |
| 5 | 5회 초과 시 동적 차단 (1시간 IP 블록) + 알림 |
지금 해야 할 것
실무자: CodeScan 무료 스캔으로 30초 점검.
CISO·임원: 통합 보안 점검은 SENTRIX 30분 1:1 상담.
결함 발견 시 24시간 안에 패치 완료가 표준이다.