What is rate limiting?

Who hits a public app that has no rate limiting?

Scripts and bots, long before most real users. A public app meets scripts that try thousands of passwords, bots that fill forms, and, if it calls an AI model, anyone who works out that each request costs you money. OWASP lists unrestricted resource consumption among the top ten API security risks.

OWASP's own example is a text message that costs $0.05 to send: an attacker who repeats the request tens of thousands of times can cost the owner thousands of dollars in minutes. Anything paid per request, such as email, SMS or an AI call, has the same shape. Our article on a Supabase bill that suddenly jumped covers how that looks from the invoice side.

Which endpoints and calls need a rate limit first?

Start with the endpoints an attacker or a bot gains most from: sign-in, sign-up and password reset; anything that sends email or SMS; every call to a paid API, especially AI models; and any request that can ask for unlimited data. Limit each by user, and by IP address where it helps:

• Sign-in, sign-up and password reset, by account and by IP address.
• Anything that sends email or SMS.
• Every call to a paid API, especially AI models, by user and in total.
• Any request that can ask for unlimited data: OWASP also recommends capping page sizes and upload sizes on the server.

For sign-in, NIST's authentication guidelines set a ceiling: no more than 100 consecutive failed attempts on one account before it is disabled. To avoid locking out real people sooner, they suggest a bot-detection challenge or a wait after each failure that grows as the limit nears, for example from 30 seconds to an hour.

What should an app return when a rate limit is hit?

The HTTP status 429 Too Many Requests, defined in RFC 6585 for exactly this case, ideally with a Retry-After header saying how long to wait. The RFC's own example allows 50 requests per hour per signed-in user and answers the 51st with a 429 and Retry-After: 3600, one hour. Well-behaved clients read that header and back off.

How do you add rate limiting to a Lovable or Supabase app?

On the server, never only in the browser, since anyone can call your endpoints directly. In practice that means the check lives in the edge function or API route that does the expensive work, counted per user and per IP address, with a total cap above both. The Lovable security checklist lists it alongside the other public-launch checks.

1. List every endpoint that sends something, costs money or checks a password.
2. Put a per-user and per-IP limit on each, answering 429 with Retry-After.
3. Set spending limits with every paid provider, as OWASP recommends, or billing alerts where a limit is not offered.
4. Log refusals, so you can tell an attack from a limit set too low.

Our guide to adding OpenAI to a Lovable app covers where those checks go, and rate limits are one of the questions in the production readiness check.