API rate limiting on every privileged surface
enforced in code, returning a uniform 429

Synchronous in-memory check, fire-and-forget Redis increment. Adds zero blocking latency to the hit path.

Returns the in-memory decision immediately so the API route does not pay a Redis round-trip on every call. The Redis INCR runs in the background and synchronises the local counter on the next request when the distributed view says the workspace is over the limit. The trade is a small enforcement lag in exchange for sub-millisecond hit latency on the common path. Used by login, signup, reset-password, scans, code-scans, AI chat, AI workspace chat, document upload, credential writes, repo writes, git OAuth start, git provider config, finding writes, bulk finding import, client creation, invoice creation, domain creation, domain verification, and the public scanner tools.

Awaits the Redis round-trip on every call. Adds roughly five to fifteen milliseconds but guarantees the distributed counter is checked before the response.

Used on the contact form endpoint, where the trade flips: a few milliseconds of latency are acceptable, but allowing a burst before Redis catches up is not. The strict variant is appropriate for public-facing surfaces that need a tight ceiling and a deterministic reject the first time the limit is exceeded.

Used on unauthenticated surfaces and on credential-stuffing-sensitive surfaces where the attacker has not yet logged in. The IP is read from x-forwarded-for, falling back to unknown if the header is missing. Per-IP gates pair well with strict ceilings because the surface is anonymous and a single host should never need a high burst.

Used on every authenticated write that has a user identity. The user.id from Supabase Auth becomes the key suffix so the limit follows the user across IPs (laptop at home, laptop on conference Wi-Fi, mobile phone) and across browser sessions. Pairs well with looser ceilings because the user is identifiable and the workspace owner can hold the operator accountable.

Used on the login endpoint after a failed credential attempt. If the IP gate is too loose to catch a stuffing attacker who rotates IPs, the per-email gate catches the second axis: the same email tried from many IPs in a short window.

The rate gate runs first as a request-shaping primitive, the role gate runs second as an authorisation primitive, and the plan quota runs third as a capacity primitive. The three layers compose without one replacing another: a member with manage_scans can still hit the per-user rate gate on /api/scans, and a Pro-tier workspace can still hit the per-month scan ceiling after the rate gate lets the request through.

Rate gate (this page)

Request shaping. Caps the rate of calls into a surface so other primitives downstream are not asked to handle a burst they were never sized for.

Role gate

Authorisation. Asks whether the actor is allowed to take the action at all. Runs after the rate gate so a denied actor still pays the same per-IP or per-user budget.

Plan quota gate

Capacity. Asks whether the workspace has remaining monthly budget for the action. Runs after the rate gate and the role gate so the capacity check is only paid by requests that were going to be allowed.

Scan authorization guards

Target validation on scan endpoints. Asks whether the workspace owns the domain being scanned. Layered on top of the rate gate so an unauthorised target is rejected after the per-user scan budget is paid.

MFA gate

Session assurance. Asks whether the session is AAL2 before any privileged action runs. Composes with the rate gate so a session that has not promoted still pays the same rate budget on the surface it tried to hit.

Per-IP gate on POST /api/auth/login at 10 attempts per 15 minutes stops the spray after the first ten guesses from that IP, regardless of which account each guess targets.

Per-email gate on POST /api/auth/login at 5 failed attempts per 15 minutes catches the rotation because the email is the same even when the IPs vary.

Per-IP gate on POST /api/auth/signup at 5 signups per 15 minutes makes single-IP free-tier farming uneconomic. Workspace creation also runs through Stripe billing on paid tiers, so the abuse path is limited to the Starter quota.

Per-user gate at 60 findings per 15 minutes catches a script that writes findings at machine speed without blocking a human security engineer doing a real triage.

Per-user gate at 5 imports per 15 minutes catches the second click on the import button and the second invocation of the import script, both of which are common operator mistakes when an import takes longer than expected.

Per-user gate at 40 messages per 15 minutes caps the per-user spend on the AI surface. Pairs with the plan-tier AI report monthly quota for the longer-cycle protection.

Per-IP gate at 10 calls per minute on each of security-headers, ssl-check, and dns-analyze stops a third party from using the free utility surface as a probe rig.

Per-IP gate at 5 resets per 15 minutes stops bulk password-reset abuse. The reset endpoint also returns the same generic response for known and unknown emails so the limiter is the only feedback the probing client sees.

Which endpoints are rate-limited?

Every authenticated write path, every authentication surface, every AI surface, every public unauthenticated surface, and every scan surface. The full list is on the limited-surfaces section of this page, named by HTTP path and key strategy.

What does the failure response look like?

HTTP 429 with a per-route error string in the JSON body. The authentication and AI endpoints additionally carry a Retry-After header with the wait time in whole seconds. The shape is identical on the Redis path and the in-memory fallback path so a client parsing the contract does not need to know which backend served the response.

Is the limiter shared across serverless instances?

Yes when UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN are set. The limiter creates a lazy singleton Redis client and uses atomic INCR with EXPIRE to share counters across every Vercel function instance.

What happens if Redis is unreachable?

The limiter falls back to per-instance in-memory enforcement rather than failing closed. A Redis outage degrades distributed enforcement to per-pod enforcement; it does not lock the workspace out of the API.

How does the limiter pair with multi-factor authentication?

MFA enforcement is a separate gate that requires session promotion to AAL2 before any privileged action. The rate limiter sits in front of the MFA verify path too, so a credential-stuffing attacker who has guessed a password still cannot brute-force the second factor through unlimited guesses.

How does the limiter pair with role-based access control?

The role check answers whether the actor is allowed to take the action. The rate limiter answers how often the actor can ask the question. A member with manage_scans hits the per-user rate gate on /api/scans the same as any other actor; the role gate decides allowed, the rate gate decides how fast.

How does the limiter pair with plan-based quotas?

Plan quotas are monthly capacity ceilings (50 scans, 20 code scans, 5 verified domains on Pro). Rate limits are short-window request-shaping caps (10 code scans per hour, 5 domain writes per 15 minutes). The two layers compose: a workspace can hit the rate gate inside a month they still have plan budget for, or hit the plan ceiling inside a window they still have rate budget for, whichever comes first.

Does the limiter protect against credential stuffing?

Yes. The login endpoint runs a per-IP gate first, then runs a per-email gate after a failed attempt. The combination defeats both single-IP credential spray and multi-IP credential rotation against one account.

Read the limited-surfaces section against the SaaS security checklist and the third-party risk assessment template. The named keys, named budgets, and named windows answer the abuse-control question without a sales call.

Read the failure modes section against the OWASP API Security Top 10. Map each defence to the corresponding API risk and capture the page as evidence in the security architecture review.

Read the failure contract and the procurement Q&A against the vendor security questionnaire. The 429 plus Retry-After shape and the named keys answer the "how does the vendor protect their API" question that shows up on most questionnaires.

Read the composition-layers section against the security architecture review. The rate gate, role gate, plan quota gate, scan authorization guards, and MFA gate are five composed primitives, and reading them as a stack helps the leadership review understand the platform security model.

Use the procurement Q&A as a copy-paste answer set for the standard rate-limiting questions on the vendor security questionnaire. The named limits, windows, and Redis behaviour answer most rows on the SIG, CAIQ, and custom questionnaires without follow-up.

Read the failure-contract section to understand the 429 parse contract. The Retry-After header is set on authentication and AI surfaces in whole seconds; other limited surfaces return a 429 with the error string and the client should respect the standard back-off the SDK wrapper applies.