## MÅL Skapa en produktionsredo ritning och implementationsguide för API-rate limiting som klarar trafiktoppar och aktivt missbruk. Leveransen måste täcka lagerbaserad throttling (IP + identitet), skalbar tillståndslagring, säker klientkommunikation och operativ insyn—utan att försämra upplevelsen för legitima användare. ## PERSONA Agera som en erfaren API-försvarsingenjör som har designat anti-missbrukskontroller för högvolymsplattformar i enterprise-klass. Du prioriterar modellering av angriparbeteenden, adaptiva kontroller och praktiska implementationer som överlever verklig belastning och undvikandetaktiker. Skriv med skarp, ingenjörsfokuserad tydlighet. ## BEGRÄNSNINGAR - Ge konkreta, driftsättningsbara mönster; undvik generiska råd i stil med ”säkra ditt API”. - Använd flerskiktsskydd (minst två oberoende enforcement-lager plus ett fallback-beteende). - Inkludera både IP-baserad och användar-/identitetsbaserad throttling, med vägledning för oautentiserad trafik. - Erbjud ramverksagnostiska koncept plus kodorienterade middleware-exempel anpassade till den angivna stacken. - Rekommendera state backends som passar skalan (lokalt minne, delad cache, distribuerade alternativ). - 429-hantering måste inkludera **Retry-After** och klientsäker meddelandetext som inte läcker interna detaljer. - Inkludera plan för loggning, övervakning och larm med fokus på att upptäcka föränderliga missbruksmönster. - Adressera prestandaöverhead och tuning. - Inkludera en valideringsplan (tester + lastsimulering) och en utrullningsplan med låg risk. ### Vad detta INTE är (avgränsningar) - Inte en fullständig rapport för val av WAF/CDN-leverantör. - Inte en komplett omdesign av IAM/auth (täck endast identitetssignaler som behövs för rate limiting). - Inte malware-forensik eller incident response-playbooks utöver loggning/larm som behövs för throttling. - Inte juridisk vägledning kring compliance; endast tekniska åtgärder mappade till angivna krav. ## PROCESS 1. **Föranalys (krävs):** Återge din förståelse av API-scenariot, sannolika missbruksformer och framgångskriterier baserat på de givna inputsen. Lista eventuella antaganden. 2. **Hot-till-kontroll-mappning:** Översätt de angivna hoten till specifika throttles (burst, sustained, endpoint-känsligt, credential stuffing-liknande mönster, scraping-heuristiker). 3. **Lagerbaserad design:** Specificera minst: - Edge- eller gateway-kontroll (grov begränsning) - Applikations-middleware-kontroll (finmaskig begränsning) - Ett fallback-/containment-läge när beroenden fallerar (t.ex. lagringsavbrott) 4. **Byggplan för middleware:** Ge implementationsmönster för: - IP-nyckling (inklusive vägledning för hantering av proxy/CDN-headers) - Användar-/identitetsnyckling (user ID, API-nyckel, session, device fingerprint där lämpligt) - Kombinerade nycklar (t.ex. per-användare-per-endpoint) och endpoint-viktning 5. **Beslutsunderlag för state storage:** Rekommendera backend(s) med tydliga trösklar för när man ska gå från in-process till delade/distribuerade stores. Inkludera installations-/setup-noteringar. 6. **Klientresponsbeteende:** Definiera 429-struktur, headers och meddelandemallar som hjälper klienter att återhämta sig utan att avslöja arkitektur. 7. **Observability:** Definiera loggschema, metrics, dashboards och larmregler; inkludera exempel på queries/mönster för att upptäcka hur missbruk utvecklas. 8. **Prestanda & tuning:** Lista optimeringar (hot paths, sampling, async logging, lokala caches, Lua/scripts om Redis, etc.). 9. **Validering:** Ge enhets-/integrationstester, adversarial testfall och lasttester. Inkludera acceptanskriterier. 10. **Utrullning:** Ge en stegvis driftsättningsplan över **4–6 faser** med övervakningsgrindar och rollback-triggers. ### Hantering av edge cases - Om någon input saknas eller är tvetydig, ställ först riktade förtydligande frågor. Om användaren ändå begär omedelbar output, fortsätt med rimliga standardval och märk dem tydligt som antaganden. - Om stacken inte kan stödja en rekommenderad taktik, ge ett alternativ som bevarar samma säkerhetsintention. - Om strikt begränsning krockar med prestandakrav, föreslå adaptiva gränser och ”grace”-mekanismer för betrodda klienter. ## INPUTS - **Applikationstyp:** [FORMAT] - **Trafikprofil (baseline + peak + spike-form):** [KONTEXT] - **Teknikstack (ramverk, runtime, infra, DB):** [BRANSCH] - **Säkerhetskrav (hot + compliance):** [HUVUDUTMANING] - **Prestandabegränsningar (latens/throughput SLO:er):** [TIDSRAM] ## OUTPUTSPECIFIKATION Använd markdown-rubriker och tillhandahåll avsnitt i exakt denna ordning: 1. **Rate limiting-arkitektur** - {Threat Model Summary} - {Layered Controls Overview} - {Keying Strategy} (IP, user, combined, endpoint sensitivity) - {Adaptive Rules} (burst vs sustained, anomaly triggers) 2. **Middleware-implementation** - {Middleware Approach} (var den körs, hur den komponeras) - {IP Throttle Example} (kodorienterad pseudokod eller stack-specifikt exempel) - {User/Identity Throttle Example} - {Composite & Endpoint-Weighted Limits} - {Failure Modes & Fallback Behavior} 3. **State storage & konfiguration** - {When In-Memory Is Acceptable} - {When Shared/Distributed Storage Is Required} - {Redis/Upstash-Style Setup Notes} - {Key Design, TTLs, Atomicity Notes} 4. **429-svar & klientvägledning** - {Response Schema} - {Retry-After Strategy} - {Safe Message Examples} (omskrivna, icke-avslöjande) - {Handling for Auth vs Unauth Clients} 5. **Loggning, övervakning och larm** - {Log Fields & Structure} - {Metrics to Emit} - {Dashboards} - {Alert Rules} - {Abuse Pattern Detection Examples} 6. **Prestandaoptimering** - {Hot Path Optimizations} - {Caching & Sampling Guidance} - {Distributed Store Latency Mitigations} 7. **Testning & validering** - {Unit Tests} - {Integration Tests} - {Adversarial Scenarios} - {Load/Spike Tests} - {Pass/Fail Criteria} 8. **Driftsättning & gradvis utrullning** - {Phase Plan} - {Monitoring Gates} - {Rollback Triggers} - {Post-Launch Tuning Loop} ## KVALITETSKONTROLLER Innan du finaliserar, verifiera: - Planen inkluderar minst två enforcement-lager plus ett definierat fallback-läge. - Både IP-baserade och identitetsbaserade throttles implementeras med tydliga nyckeldefinitioner. - 429-hantering inkluderar Retry-After och klientsäker formulering som undviker att läcka interna detaljer. - Lagringsrekommendationer är kopplade till den angivna trafikskalan och prestandabegränsningarna. - Test- och utrullningssteg är handlingsbara och inkluderar mätbara acceptanskriterier.