Abuse prevention
Protect sign-in and other public authentication endpoints from bursts of automated traffic.
Better Auth · Pipe
rateLimit
Better Auth provides a built-in limiter for client-initiated requests. Configure its window, request ceiling, storage, and path-specific rules through betterAuth's rateLimit option.
How it works
Better Auth applies rate limiting to client-initiated requests and tracks requests using the connecting IP address. Configure it through the rateLimit option passed to betterAuth; production enables it by default, while development requires enabled: true.
Syntax
betterAuth({ rateLimit: { enabled?, window?, max?, customRules?, storage?, modelName? } })Parameters
| Name | Type | Description |
|---|---|---|
enabled | boolean | Turns rate limiting on or off; defaults to true in production and false in development. |
window | number | Length of the rate-limit window, measured in seconds; default 10. |
max | number | Default maximum requests permitted within the window; default 100. |
customRules | object | Rules that override limits for specific paths. |
storage | "memory" | "database" | "secondary-storage" | Where rate-limit data is stored: memory, database, or secondary-storage; default memory. |
modelName | string | Database table name used when database storage is selected; default rateLimit. |
Key points
- Add rateLimit to betterAuth to configure the limiter globally for the authentication instance.
- The default production window is ten seconds.
- The default production allowance is 100 requests per window.
- Request counts are associated with the connecting IP address.
Common mistakes
- Calls made through auth.api on the server bypass this limiter, so server-side code should not assume the same protection as browser or client requests.
- Development environments need enabled: true when you want to exercise or verify the limiter locally.
Example: Configure rate limiting
import { betterAuth } from "better-auth";
export const auth = betterAuth({
rateLimit: {
enabled: true,
window: 10,
max: 100,
storage: "memory",
},
});Creates a Better Auth instance with a ten-second window and permits up to 100 client requests in that window.
When to use it
Endpoint-specific policies
Apply tighter or looser thresholds to selected paths with customRules.
Distributed deployments
Use shared persistence when several application instances must observe the same counters.
Development testing
Enable the limiter in local development to reproduce production behavior.
Interview questions
QHow is rate limiting configured?
The rateLimit option configures Better Auth's built-in limiter. Its main controls are enabled, window, and max, with optional customRules, storage, and modelName settings.
Follow-up: How would you persist limits across multiple application instances? Configure a shared storage option, such as database or secondary-storage, instead of relying on the default in-memory storage.
QWhat are the default settings?
In production, rate limiting defaults to enabled; in development, it defaults to disabled. The default window is 10 seconds and the default maximum is 100 requests.
Follow-up: How would you test this behavior during local development? Explicitly set enabled: true and use a small window or maximum in a test configuration.
QWhich requests are counted, and how are they identified?
The limiter applies only to client-initiated requests and uses the connecting IP address to count requests. Server-side requests made with auth.api are excluded.
Follow-up: What limitation follows from IP-based tracking? Multiple users sharing an IP can consume the same limit, while clients whose apparent IP changes can be tracked inconsistently.
Related
betterAuthcustomRulesstoragemodelNameauth.api