Hvornår I skal rate-limite — og hvad I faktisk limiter

Et endpoint uden loft er en faktura, I ikke har skrevet under på. Login hasher. Søgning læser. Webhooks skriver. En model koster pr. token. En scraper, et stuffed login, et 'prøv alle CVR-numre'-script, et webhook I selv kaldte i et loop — det er samme klasse: nogen har fundet det dyre, og I betaler, indtil I siger nej. Loftet er ikke paranoia. Det er at nægte at subsidiere det, I ikke ville køre i hånden.

Teams arver ordet rate limiting fra et andet lag. I et edge-event er det 'blokér landet'. I en API-gateway er det tokens pr. nøgle. I en Next.js-route er det ofte en middleware, nogen kopierede, der tæller forkert, viser 500, og rammer den forkerte sti. I tror I har beskyttet API'et. I har flyttet smerten til forsiden, eller I har et loft, der nulstilles hver gang en instans starter. Ritualet er dyrt, fordi det giver jer tilladelse til ikke at pege på det kald, der faktisk gør ondt.

Det er også et tillids- og produkts-spørgsmål. En 429 uden Retry-After er en fejl, brugeren skyder på jer. En 403 på et login, der bare var for hurtigt, er en lockout I ikke kan forklare. En captcha foran hele sitet, fordi I ikke ville eje et loft på `/api/search`, er teater: I straffer den, der læser, for at I ikke ville begrænse den, der scraper. Hvis ingen ejer 429-siden, er loftet et netværkssignal. Det er ikke et produkt.

Vi skriver det, fordi 'vi skal beskytte API'et' er blevet et køb, I tager før I har en sætning om hvilket kald, hvilken identitet og hvilken 429. Et ærligt setup er kedeligt: loft på login, søgning, webhooks og det, der kalder videre; delt tæller; ærlig status. Uden den sætning har I en WAF-regel med et tal. I har ikke rate limiting.

Rate limiting er et loft på et navngivet kald i et navngivet vindue: så mange loginforsøg pr. konto og pr. IP pr. kvarter, så mange søgninger pr. session pr. minut, så mange webhook-retries pr. kilde. Den er et produktvalg, fordi den siger hvem I tror I er, og hvad I accepterer at køre. Den er ikke et skældsord. De fleste offentlige sites skal have den på tre stier, ikke på alle.

Det er ikke 'blokér bots'. En WAF, et managed challenge, et bot-score, er et andet job: at holde det grove ude, før det rammer origin. Det er rigtigt, og det er ikke loftet. Loftet er det, der sker når kaldet allerede er jeres — en rigtig bruger, en rigtig nøgle, en rigtig form — og I stadig siger nej, fordi det er for ofte. Hvis I kun har WAF, har I et håb om at det dyre kald ikke kommer ind. I har ikke sagt nej til det, der kom ind.

Det er heller ikke 'sæt et tal på hostname'. En global request-limit rammer den side, I gerne vil have crawlet, og lader `/api/login` være det, der overlever, fordi det er færre bytes. Angriberen vælger det dyre. I limiter det billige. Et ærligt loft starter med sætningen 'det her kald koster os X i CPU, i vendor, i lockout-risiko' — kvalitativt, ikke som et dashboard-teater. Uden den sætning er tallet indretning.

Og det er ikke en in-memory Map i en serverless-funktion. Tre instanser, tre tællere, tre gange loftet. En deploy, og tælleren er glemt. Rate limiting, der ikke overlever en ny instans, er en suggestion. Brug noget delt: KV, Redis, et platform-rate-limit, edge-cache med nøgle. Vælg det kedelige, der tæller rigtigt. Et klogt tal på tre huller er stadig tre huller.

Den første fejl er at limite det synlige, ikke det dyre. I sætter et loft på `/` fordi det er det, I kan se i CDN-loggen, og lader `/api/search`, `/api/auth` og webhook-routen køre. I har flyttet grafen. I har ikke flyttet risikoen. Et ærligt loft starter med det kald, I ikke vil køre i et loop med hånden. Hvis I ikke kan pege på det, er I ikke klar til et tal. I er klar til at læse jeres egne routes.

Den anden fejl er tælleren, I ikke delte. Next.js på Vercel, Cloudflare Workers, to regioner, preview og prod. En Map i modulet, en cookie I selv sætter, en edge-middleware uden storage. Det virker i ét vindue. Det virker ikke når tre isolates tager de næste tre requests. I får et loft I kan demo'e, og et hul I betaler for. Delt state er pligten. Alt andet er et lokal-loft, I kalder globalt.

Den tredje fejl er statuskoden og kroppen. En 500 på for mange logins er en løgn: I ved præcis hvad der skete. En 200 med `{ ok: false }` er et hul, klienten ikke kan skelne fra validering. En 403, som om brugeren var bandlyst, er en lockout I ikke kan forklare til support. 429 er ordet. Retry-After er tiden. UI'et skal sige 'prøv igen om et øjeblik', ikke 'noget gik galt'. Fejlsider-indlægget er skærmen. Her er pligten at lade loftet være sandt i headeren.

Den fjerde fejl er at købe identitetsteater før I har et loft. 'Vi venter på SSO, så limiter vi.' Imens er den offentlige søgning og den offentlige formular åbne. I kan limite på IP og på cookie, indtil I har en bruger. Det er groft. Det er bedre end ingenting. En NAT er et problem, I kan rumme med et højere loft og et sekundært signal. Ingen identitet er ikke en grund til at lade `/api/login` køre ubegrænset.

Login og password-reset er det loft, der oftest er rigtigt af lockout-risiko, ikke af CPU. I vil ikke hashe et væld af gæt. I vil ikke sende en bunke reset-mails. Identitet slår IP, når I har en konto. IP slår ingenting, når I ikke har. Et ærligt login-loft er stramt pr. konto, grovere pr. IP, og en 429 der ikke lyder som 'forkert adgangskode'. Bland de to, og I har givet en angriber et orakel. Sikkerheds-indlægget er headers og hemmeligheder. Her er pligten at lade gættet være dyrt for dem, ikke for jer.

Søgning og 'typeahead' er det loft, der oftest er rigtigt af origin-regning. Hvert tastetryk er et databasekald, medmindre I cacher. En scraper, der elsker jeres `/api/search`, er ikke en læser. Et globalt hostname-loft rammer bloggen. Et loft på søge-routen rammer jobbet. Cache det, I kan. Limit det, I ikke kan. Hvis I 'beskytter API'et' ved at kræve login for at søge i et offentligt katalog, har I flyttet produktet. I har ikke flyttet loftet.

Webhooks ind og ud er det loft, I glemmer, indtil en partner retrier i et loop, eller indtil jeres eget job kalder jer selv. Signér hemmeligheden. Idempotens på event-id. Og et loft pr. kilde, så en mislykket handler ikke bliver en denial, I har betalt for. Det er ikke 'beskyt API'. Det er at nægte at lade et loop, I selv har, ligne trafik. Observability-indlægget er at se det. Her er at sige nej, når I har set det nok.

Den offentlige formular — kontakt, 'book en samtale', newsletter — er det loft, der oftest bliver til captcha-teater. Captcha kan være rigtigt, når I har et menneske foran en dyr handling. Den er forkert som erstatning for et loft: I kan limite pr. IP og pr. felt-hash, skjule honeypot, og stadig vise formularen. Cookie-banner-indlægget er samtykke. Den her er at lade spam være dyrt, uden at straffe den, der skriver tre linjer i god tro. Et portal-landing er det, I bygger, når formularen er blevet et arbejdsgang — ikke når I bare skulle have sagt 429.