Skip to main content

Edge Case: API Rate Limiting and Abuse Prevention

non-critical   Property: ChurchWiseAI   Category: Security Tier: all Persona: security-tester Touchpoint: /api/chatbot/stream, /api/contact, /api/newsletter

Preconditions

  • Rate limiting middleware is configured
  • Tests run in serial mode (rate limits consumed per test)
  • Retries: 2 to handle instance variability in serverless

Steps

#ActionExpected Result
1Send 35 rapid chatbot requests with fake churchIdAt least one request returns 429 Too Many Requests. Rate limit enforced.
2Send 8 rapid contact form submissions with empty dataAt least one request returns 429. Contact form rate limit enforced.
3Send 8 rapid newsletter subscribe requestsAt least one request returns 429. Newsletter rate limit enforced.
4Send 15 voice agent webhook requests (SIP invite)At least one returns 429. Voice agent abuse protection active.
5Wait 5 seconds after hitting rate limitSubmit another request. Returns 200 (rate limit reset). Temporary throttling works.
6Send requests from multiple sessions (different sessionIds)Rate limiting applies per client IP or globally, not per session. System prevents multi-session bypass.
7Send requests spread across 60 seconds (1 per second)All requests succeed (status 200 or 400, never 429). Legitimate slow traffic not throttled.

Known Failure Modes

  • No 429 response after 35 requests — rate limiting not enforced
  • Rate limit never resets — temporary IP ban too aggressive
  • Multi-session bypass possible — abuse vector remains
  • Legitimate slow traffic throttled — false positives

References

Notes

Tests rate limiting across multiple endpoints. Vercel serverless spreads requests across instances, so rate limiting is probabilistic — tests use retries: 2 to handle flakiness. Tests must run in serial mode to properly consume quota. Rate limiting should trigger at ~30-35 reqs in 1 second for chatbot, ~8 for contact form. Legitimate slow traffic (1 req/sec) should never be throttled.