Begränsning av betyg: skydda ditt API utan att blockera riktiga användare
Rate begränsande stoppar en dålig skådespelare - eller en buggy script - från att hamra din webbplats i marken, utan att smälla dörren på alla andra. Att välja gränser är den svåra delen.
Begränsningstak visar hur många förfrågningar en klient kan göra i ett tidsfönster. Den skyddar inloggningsformulär, sökningar och API:er från brute force, skrapning och runaway-skript. Mekanismen är enkel; plocka gränser som stoppar angripare utan att fånga riktiga människor är den del som tar tanke - särskilt eftersom hela kontor och mobila nätverk delar en enda IP-adress.
Varje webbplats har några slutpunkter som lockar problem. Inloggningsformuläret, återställningen av lösenordet, sökrutan, det offentliga API:et. Lämnas obevakad, kan ett skript slå dem tusentals gånger i sekunden - gissa lösenord, skrapa katalogen eller bara fungera entusiastiskt för att någon glömde en paus uttalande.
Rate limiting är det tak som säger "det räcker". Tanken tar en mening; att få det rätt tar lite mer.
Idén
Ge varje kund ett rimligt antal förfrågningar per tidsenhet och avvisa eller sakta ner de som överskrider dem. En person som klickar runt på en webbplats gör kanske tio förfrågningar per minut. Ett brutalt manus gör tusentals. Det finns en enorm mängd utrymme mellan dessa två siffror, vilket är vad som gör att det här fungerar alls.
Vilken algoritm och varför det är viktigt
Det finns tre vanliga tillvägagångssätt och skillnaden mellan dem är mer praktisk än det låter.
Fast fönster
Räkna förfrågningar per kalenderminut; återställ räknaren högst upp i varje minut. Enkelt, billigt, och det har en uppenbar brist: en klient kan göra sin fulla ersättning vid 10:00:59 och dess fulla ersättning igen vid 10:01:00, leverera dubbelt den avsedda kursen i en två sekunders burst. Bra för grov skydd, inte för något du bryr dig om.
Glidfönster
Räkna antalet förfrågningar under de efterföljande sextio sekunderna i stället för den aktuella kalenderminuten. Detta stänger gränshålet och är vad de flesta människor faktiskt vill ha när de säger "100 förfrågningar per minut".
Tokenskopa
Tänk dig en hink med 60 polletter som fylls på en gång per sekund. Varje begäran spenderar en token. Förfrågningar i en förnuftig takt dränera aldrig det; en burst kan spendera flera på en gång, och ihållande översvämning tömmer det och blir vägrat tills det fylls på.
Token hink är vanligtvis rätt standard, eftersom det matchar hur verklig användning faktiskt ser ut. En person som laddar en sida avfyrar ett dussin förfrågningar på en gång och gör sedan ingenting i trettio sekunder. En strikt per sekund-gräns straffar det helt normala beteendet; en skopa absorberar det.
Att välja gränser
Misstaget är en global gräns som tillämpas överallt. Dina slutpunkter har väldigt olika riskprofiler och väldigt olika legitima användningsmönster, så de vill ha väldigt olika siffror.
| Slutpunkt | Utgångspunkt | Överskrider |
|---|---|---|
| Logga in, återställ lösenord | 510 per minut per IP | Utmaning, sedan blockera |
| Anmälan, kontaktformulär | 35 per minut per IP-adress | Utmaning |
| Sök | 2030 per minut per IP | Gasreglage |
| Offentligt API, oautentiserat | 60 per minut per IP | 429 med försök efter |
| Offentligt API, per API-nyckel | Per din plan nivåer | 429 med försök efter |
| Allmän sidasökning | 300+ per minut per IP-adress | Gasreglage |
Det är utgångspunkter, inte rekommendationer för din webbplats – rätt siffror kommer från att titta på din egen trafik. Ta en vecka med loggar, hitta den 99:e procentsatsen för begäran om verkliga sessioner på varje slutpunkt och sätt gränsen på ett meningsfullt sätt ovanför den. Om din mest trafikerade användare gör 40 sökningar per minut kommer en gräns på 30 att generera arga e-postmeddelanden.
Den delade IP-fällan
Det här är den som fångar människor, och den fångar dem på ett sätt som är osynligt från din sida.
En enda IP-adress är ofta inte en enda person. Ett kontor med 200 personer bakom en NAT-gateway är en IP-adress. Ett universitetscampus är en IP-adress. Mobiloperatörer lägger rutinmässigt tusentals abonnenter bakom NAT av operatörskvalitet och delar en handfull adresser. VPN-tjänster för företag koncentrerar ett helt företag till en enda utgångsnod.
Ange en aggressiv per-IP-gräns och du blockerar inte en missbrukande användare, du blockerar alla på det företaget, och de upplever det som "din webbplats är trasig" snarare än "vi har varit begränsade". De kommer inte att maila dig. De kommer bara att gå.
Om du kan, betygsätt gränsen för något mer specifikt än en IP – en API-nyckel, en session, ett användarkonto. För oautentiserad trafik där IP-adressen är allt du har, föredra en utmaning framför ett hårt block när gränsen går. Ett delat kontor klarar utmaningen och fortsätter; ett manus gör det inte.
Misslyckas artigt
När du avvisar en förfrågan, gör det på det sätt som standarden förväntar sig, eftersom klienten i andra änden kan mycket väl vara en legitim integration som kommer att bete sig korrekt om du berättar hur.
Återgå 429 för många förfrågningar inte 403, vilket betyder "du är inte tillåten", ett annat och oåterkalleligt meddelande. Inkludera en Retry-After En header som visar hur länge man ska vänta. Om du kör ett offentligt API skickar du det aktuella gränstillståndet på varje svar, inte bara avslagen, så en välskriven klient kan sakta ner innan den träffar väggen snarare än efter.
Och håll dina svar på prisgränsen billiga. Om det kostar dig en databasfråga att avvisa en begäran kan en bestämd angripare fortfarande göra dig utmattad med hjälp av inget annat än avslag. Detta är ett annat argument för att begränsa vid kanten, där avslag sker innan din ansökan alls är inblandad.
Saker som är värda att undantas
- Verifierade sökrobotar. Googlebot kryper in och begränsar hastigheten så att den kan skada din indexering tyst. Kontrollera och undanta.
- Din egen övervakning. Drifttidskontroller från en fast adress bör inte konkurrera med dina gränser.
- Webhook-avsändare. Betalningsleverantörer försöker igen aggressivt genom design; en gräns som blockerar dem kan förlora dina beställningar.
- Statiska tillgångar. En sidvisning innehåller dussintals begäranden om tillgångar. Att begränsa dem per IP fångar normal surfning omedelbart.
Vanliga frågor
Vad är Rate Limiting?
Betygsätt hur många förfrågningar en enskild kund kan göra inom en viss tidsperiod, och avvisa eller sakta ner något utöver det. Det skyddar inloggningsformulär, sökslutpunkter och API:er från försök med brute force, skrapning och felaktigt skript, samtidigt som normal användning förblir orörd eftersom legitim trafik ligger långt under tröskeln för en angripare. behov.
Vad är en bra prisgräns för ett API?
Det beror på slutpunkten snarare än platsen. Inloggnings- och lösenordsåterställningsslutpunkter motiverar 5 till 10 förfrågningar per minut per IP, anmälningsformulär 3 till 5, sök 20 till 30 och ett oautentiserat offentligt API runt 60. Härleda dina faktiska siffror från dina egna loggar genom att hitta den 99: e percentilen begäran takt av äkta sessioner och ställa in gränsen bekvämt över den.
Vilken HTTP-statuskod ska en kursgräns returnera?
429 För många förfrågningar, tillsammans med ett Retry-After-huvud som anger hur länge kunden ska vänta. Använd inte 403 Forbidden, vilket signalerar att klienten inte är tillåten alls snarare än att den ska sakta ner och försöka igen. Offentliga API:er bör också returnera nuvarande gränstillstånd för lyckade svar så att kunderna kan strypa innan de avvisas.
Varför blockerar hastighetsbegränsande riktiga användare?
Nästan alltid eftersom många människor delar en IP-adress. Kontor bakom en NAT-gateway, universitetscampus, företags-VPN och mobiloperatörer som använder NAT av operatörskvalitet kan lägga hundratals eller tusentals äkta användare bakom en enda adress. En per IP-gräns som är inställd för en person blockerar därför alla. Begränsa API-nyckeln, sessionen eller kontot där det är möjligt, och föredra en utmaning framför ett hårt block annars.
Vad är token hink algoritmen?
Tokenskopan modellerar en skopa med ett fast antal tokens som fylls på i jämn takt. Varje begäran förbrukar en token, och begäran avvisas när skopan är tom. Detta tolererar korta skurar, vilket är hur verklig surfning beter sig, samtidigt som det täcker ihållande begäran priser - vilket gör det bättre för webbtrafik än en strikt fast fönsterräknare.
Hastighetsbegränsning är en av de kontroller där standardkonfigurationen sällan är rätt och rätt konfiguration sitter i dina åtkomstloggar. Tillbringa en timme med en veckas trafik innan du väljer dina nummer, och du kommer att undvika den mycket längre eftermiddagen för att räkna ut varför en kunds hela kontor inte kan logga in.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
