Tom Hundley
🤖 Ghostwritten by GPT 5.4 · Fact-checked & edited by Claude Opus 4.6
Rate limiting is one of the fastest ways to make a vibe-coded app safer and cheaper to run. It puts a cap on how many times someone can hit your app — or a specific action like login, signup, password reset, or "send email" — within a set period. Without it, a single bad actor can keep knocking on the same door: trying passwords, scraping data, triggering paid API calls, or simply overwhelming the app.
That matters even more for vibe coders because many AI-built apps are wired to paid services from day one. A single unthrottled endpoint may call an LLM, send an email, trigger an SMS, write to a database, or launch a workflow that costs money every time it runs. In that setup, abuse is not just a security problem — it is an operating-cost problem.
The timing is worth noting. Reporting in early May 2026 about the RedAccess "Shadow Builders" findings described researchers scanning hundreds of thousands of vibe-coded apps and finding thousands with no authentication at all, with a significant share leaking sensitive data. Even after authentication is added, rate limiting remains a foundational control because a login page with no throttle still invites brute-force attempts and cost abuse.
TL;DR: Authentication answers "who are you," but rate limiting answers "how often are you allowed to try" — and both are required.
A common mistake in AI-built apps is treating login as the finish line. It is not. Login only creates a gate. If that gate allows unlimited attempts, an attacker can still automate password guessing, enumerate user accounts, or hammer password-reset flows until something breaks.
This is where brute-force protection starts. A brute-force attack is simply repeated guessing at high speed. Without rate limiting, software can try credentials far faster than any human ever could. That turns a basic login form into an attack surface.
The same logic applies outside login:
For vibe coders, the financial angle is especially important. Security teams sometimes call this a "denial of wallet" attack: instead of knocking an app offline directly, the attacker drives up the bill by repeatedly triggering paid operations. If an endpoint calls an LLM, image model, email provider, SMS gateway, speech API, or other metered service, unlimited requests can become expensive very quickly.
A useful mental model: authentication decides whether someone may enter, while rate limiting decides how fast they can move once they reach the door. Both matter. Neither replaces the other.
| Control | What it does | What it does not do |
|---|---|---|
| Authentication | Verifies identity before allowing access | Does not stop unlimited retries or high-volume abuse |
| Rate limiting | Caps request volume over time | Does not prove the user is legitimate |
| CAPTCHA | Adds friction to automated abuse | Does not replace rate limits or lockouts |
| Lockout / cooldown | Temporarily blocks repeated failed attempts | Does not protect expensive non-login endpoints by itself |
TL;DR: Rate limiting means setting a maximum number of requests per user, IP, token, or action within a time window, then slowing or blocking excess traffic.
Rate limiting sounds technical, but the idea is simple. Pick a thing you want to protect, decide how many times it should be allowed in a period, and define what happens when someone exceeds that amount.
Examples:
The exact numbers vary by app, but the pattern is consistent: protect scarce or risky actions more aggressively than ordinary page loads.
There are several ways to apply rate limiting:
The simplest starting point. If one network address sends too many requests too quickly, the app slows or blocks that traffic. Useful but imperfect — multiple users may share an IP, and attackers can rotate addresses.
Helps when the attacker is logged in or targeting a specific account flow. Especially useful for login attempts, password resets, and paid actions.
Works well for apps with team accounts or API access. Prevents one customer environment from consuming excessive shared resources.
Often the most important layer for vibe apps. Not every route needs the same limit. A health-check endpoint is different from "generate report," "send SMS," or "create image."
Good implementations allow short bursts but block sustained abuse. A user might be allowed a few quick actions in a minute, but not hundreds over an hour.
One practical note: rate limiting reduces abuse but does not eliminate it. Attackers can distribute traffic, use bot networks, and adapt. That is why rate limiting works best as part of defense-in-depth, alongside authentication, CAPTCHA, lockouts, logging, and provider-side spending controls.
TL;DR: Start with endpoints that unlock accounts, send messages, expose data, or trigger paid APIs — those are the easiest places for abuse to become expensive or damaging.
If time is limited, not every route needs equal attention on day one. The fastest win is to identify the endpoints that are easiest to abuse or most expensive per request.
Classic brute-force targets. Add rate limiting per IP and per account, plus a temporary lockout or cooldown after repeated failures. This reduces credential stuffing and password guessing.
Open signup flows are magnets for bot traffic. Add rate limits and a CAPTCHA. If email verification exists, make sure the verification-send action is also limited so it cannot be abused as a mail cannon.
Often forgotten. They can be abused to spam users, discover whether an account exists, or overwhelm messaging providers.
These actions cost money and can damage sender reputation if abused. They should have strict per-user and per-IP limits.
LLM completions, image generation, transcription, embeddings, document parsing, enrichment APIs, premium search APIs. These endpoints are prime denial-of-wallet targets.
Even if they do not cost much per call, they may expose sensitive data to scraping. Rate limiting helps slow automated harvesting.
| Endpoint type | Main risk | Recommended baseline controls |
|---|---|---|
| Login | Brute force, credential stuffing | Rate limiting, failed-login lockout, monitoring |
| Signup | Bot account creation, spam | Rate limiting, CAPTCHA, email verification |
| Password reset | Account enumeration, message spam | Rate limiting, generic responses, cooldown |
| Send email/SMS | Cost abuse, spam, reputation damage | Strict rate limits, quotas, provider alerts |
| LLM or AI generation | Denial of wallet | Per-user limits, daily quotas, spending alerts |
| Export/search | Scraping, data harvesting | Rate limiting, pagination limits, monitoring |
OWASP has long emphasized automated attack patterns such as credential stuffing and brute force in its guidance on authentication security. The point for vibe coders is straightforward: the endpoints that feel most useful to legitimate users are often the same endpoints an attacker can automate most easily.
TL;DR: Protect the obvious attack paths first, then add provider-side cost controls so abuse cannot quietly turn into a billing incident.
A good first pass does not require a full security program. It requires a short list and disciplined defaults.
List every route or action that fits one of these categories:
If an action costs money per request, it belongs on the list even if it already requires login.
Start with login, signup, password reset, and every paid action. Use tighter limits on expensive or sensitive endpoints than on general browsing or low-risk reads.
CAPTCHA is not elegant, but it is effective friction on signup and similar public forms. Especially useful when a route can trigger message sends or account creation.
Core brute-force protection. Even a short cooldown after multiple failed attempts can sharply reduce automated guessing.
This is the cost-protection step many builders skip. If a provider supports hard budget caps, usage thresholds, or alerting, turn them on. If a provider does not support hard caps, create internal daily quotas and alerts around the endpoint that calls it.
Watch for sudden traffic bursts, repeated 401 or 403 responses, unusual signup velocity, and steep jumps in provider usage. Abuse prevention works better when it is observable.
Cloudflare and major API gateways offer native rate-limiting controls, and most modern frameworks support middleware for endpoint-level throttling. The exact tool matters less than the policy: identify the expensive and high-risk actions, then cap them intentionally.
Here is a prompt you can hand to a coding agent:
Audit this application for abuse-prone and cost-sensitive endpoints. Find every route, action, job trigger, webhook, or function that could be hammered by an attacker or that costs money per request — including login, signup, password reset, email sends, SMS sends, file uploads, search, exports, LLM calls, image generation, transcription, embeddings, and any third-party API calls. For each one, recommend a rate-limit strategy in plain English and implement sensible defaults in code. Add brute-force protection for login, CAPTCHA on signup if appropriate, lockouts or cooldowns after repeated failed logins, and logging for limit violations. Also produce a separate list of all paid providers used by the app and recommend spending caps, budget alerts, daily quotas, or fail-safe cutoffs for each. Return the results as: 1) endpoint inventory, 2) risks by endpoint, 3) code changes made, 4) remaining gaps, and 5) recommended spending-cap settings.
That prompt forces the agent to look beyond authentication and into cost-triggering behavior — often where the biggest practical risk sits in AI-built apps.
Rate limiting is a cap on how often someone can use your app or a specific feature within a set time window. For example, a login form might allow only five attempts in 15 minutes, or an AI generation endpoint might allow only a certain number of requests per user per day. The goal is to let normal usage through while blocking automated abuse.
No. Login and rate limiting solve different problems. Authentication checks identity, while rate limiting reduces repeated attempts, bot traffic, scraping, and cost abuse against both public and authenticated actions. An authenticated user can still abuse expensive endpoints without rate limits in place.
A denial-of-wallet attack is when someone repeatedly triggers metered services so the app owner gets charged for each call. In vibe-coded apps, this often means abusing endpoints tied to LLMs, email, SMS, image generation, transcription, or other paid APIs. Unlike a traditional denial-of-service attack that aims to crash a server, denial of wallet aims to drain a budget.
Start with login, signup, password reset, any endpoint that sends messages, and any endpoint that calls a paid API. After that, review export, search, upload, and bulk-read routes that could be scraped or used to consume infrastructure heavily.
No. CAPTCHA helps reduce bot activity, especially on signup, but it is only one layer. Determined attackers use CAPTCHA-solving services. Stronger abuse prevention combines rate limiting, CAPTCHA, lockouts, authentication, logging, and spending caps or alerts on paid services.
The RedAccess reporting from early May 2026 was a reminder that many vibe-coded apps still ship without basic protections. The next lesson is just as important: an app can have a login screen and still be dangerously open if every sensitive or expensive action is unlimited. As AI-built software becomes more connected to metered services, rate limiting and abuse prevention are no longer optional hardening steps. They are part of the minimum viable architecture for shipping something that can survive contact with the public internet.
Discover more content:
