API'er, misbrug og omkostninger

Beskyt appen mod botter, spam og løbsk forbrug

En funktion kan være korrekt bygget og stadig være farlig, hvis den kan gentages uden rimelige grænser. Offentlige formularer, bookinger, loginforsøg, nulstillingsmails og AI-kald kan automatiseres, så de spærrer for rigtige brugere eller skaber en uventet regning. Beskyttelsen skal derfor følge handlingens virkning – ikke kun besøgendes IP-adresse.

Udgivet 11. september 2026 · Ca. 11 minutters læsetid

Find de handlinger, som kan misbruges

Start ikke med at vælge en vilkårlig grænse for hele API'et. Kortlæg de flows, hvor mange eller hurtige gentagelser kan skade virksomheden, brugerne eller driften. OWASP skelner blandt andet mellem ukontrolleret ressourceforbrug og overdreven brug af et følsomt forretningsflow. Det første kan belaste compute, lager eller betalte tjenester; det andet kan eksempelvis fylde kalenderen med falske bookinger, selv om serveren teknisk set kan håndtere trafikken.

Flow	Mulig skade	Mål, der giver mening
Login og nulstilling	Gæt, kontolåsning, mailstøj og brugeropslag	Forsøg pr. konto og flow samt supplerende netværkssignal
Booking og tilmelding	Falske reservationer eller udtømte pladser	Konto, kontaktpunkt, ydelse og tidsvindue
Kontakt og kommentarer	Spam, moderationsarbejde og støj i CRM	Session, mønster, modtager og dokumenteret volumen
AI, rapporter og eksport	Løbsk forbrug, køer og langsom app	Bruger, virksomhed, samtidighed og samlet kvote

Sæt grænsen efter aktør, omfang og virkning

En enkelt global tæller er sjældent retfærdig eller sikker. Mange legitime brugere kan dele en offentlig IP, mens en angriber kan sprede requests over mange adresser. Kombinér derfor kun de signaler, som flowet kan bære, og lad en stærkere identitet veje tungere, når brugeren er logget ind.

Kort spidsbelastning: Tillad normal dobbeltklik og hurtig navigation, men stop et unaturligt request-burst.
Vedvarende forbrug: Begræns samlet brug over et længere vindue, især når hvert kald koster penge eller kapacitet.
Samtidighed: Begræns hvor mange tunge jobs én bruger eller virksomhed kan have i gang på samme tid.
Forretningskvote: Sæt en forståelig ramme for fx reservationer, modtagere eller genereringer efter den aftalte brug.

Talværdier skal komme fra normal brug, leverandørgrænser, kapacitet og den konkrete skade – ikke fra et eksempel fundet på nettet. Dokumentér ejer, målepunkt, vindue, undtagelser og hvad brugeren oplever, når grænsen rammes.

Håndhæv begrænsningen på serveren

Deaktivering af en knap i browseren stopper ikke et direkte API-kald. Tælleren og beslutningen skal ligge ved den ressource, der udfører arbejdet: endpoint, gateway, funktion, kø eller database. Ved flere serverinstanser skal de dele en tæller eller bruge platformens centrale rate-limiting-funktion; en lokal variabel pr. proces giver forskellige grænser afhængigt af, hvilken instans requestet rammer.

Afvis tidligt: Kontrollér simple grænser før dyr parsing, databasearbejde og kald til en betalt leverandør.
Tæl atomisk: Parallelle requests må ikke alle læse samme gamle værdi og derefter slippe igennem.
Begræns input: Sæt også maksimum for payload, filstørrelse, sidelængde og antal elementer, hvor flowet tillader det.
Hold rettigheder adskilt: Rate limiting erstatter aldrig login, autorisation eller kontrol af den enkelte datapost.
Beskyt hele kæden: Et loft ved indgangen hjælper ikke, hvis baggrundsjobbet bagefter kan starte ubegrænset arbejde.

Svar ærligt, når grænsen er nået

HTTP-status 429 betyder, at klienten har sendt for mange requests inden for et givet tidsrum. Svaret kan indeholde Retry-After, så klienten ved, hvornår et nyt forsøg giver mening. Vis samtidig en almindelig dansk besked, der forklarer om brugeren skal vente, afslutte et igangværende job eller kontakte den ansvarlige. Skjul interne tællernøgler og forsvarsdetaljer.

Undgå en retry-storm. Hvis appen automatisk gentager alle 429- eller overbelastningssvar med det samme, bliver presset større. Respektér leverandørens ventetid, brug kontrolleret backoff, og lad brugerfladen vise, at arbejdet venter i stedet for at starte skjulte kopier.

Brug botkontrol som et ekstra lag

En challenge kan gøre automatisering dyrere, men den er ikke en erstatning for grænser, datavalidering eller adgangskontrol. OWASP anbefaler at se CAPTCHA som et ekstra beskyttelseslag. Overvej først en ekstra kontrol, når adfærden er risikabel – eksempelvis efter flere mislykkede forsøg – så alle legitime brugere ikke møder unødig friktion.

Ved Cloudflare Turnstile skal serveren validere tokenet; widgetten i browseren beskytter ikke endpointet alene. Turnstile-tokens er ifølge den aktuelle dokumentation gyldige i fem minutter og kan kun valideres én gang. Kontrollér også forventet hostname og action, når de er en del af opsætningen, og test både udløb, fejl og genbrugte tokens.

Firebase App Check kan tilsvarende attestere, at requests kommer fra en app eller enhed, som projektet accepterer. Firebase beskriver selv løsningen som beskyttelse mod nogle, men ikke alle, misbrugsvektorer. Den supplerer Firebase Authentication; den erstatter hverken brugerlogin, Security Rules eller flowets egne kvoter. Mål mængden af verificeret og afvist trafik før håndhævelse, og hold eventuelle debug-tokens ude af kode og produktion.

Overvåg virkning – ikke bare blokeringer

En stigende mængde 429-svar kan være et angreb, en fejlende klient eller en legitim arbejdsgang, der er vokset. Log derfor flow, beslutning, tidsvindue og en dataminimeret reference til aktørens type. Følg samtidig den virkelige virkning: sendte mails, oprettede bookinger, AI-forbrug, kølængde, svartid og leverandørens afvisninger.

Alarmér på vedvarende afvigelser og omkostningsdrivere – ikke på hvert enkelt afvist request.
Skeln mellem anonyme, loggede og system-til-system-kald, så ét mønster ikke skjuler et andet.
Gem ikke adgangskoder, challenge-tokens, sessionstokens eller hele formularer i loggen.
Knyt et nødstop eller en reduceret drift til de dyreste flows, hvis normal begrænsning ikke er nok.
Gennemgå falske positiver: rigtige brugere skal kunne komme videre uden at support omgår hele kontrollen.

Test normale, parallelle og fordelte forsøg

Test i et kontrolleret miljø med leverandørernes testfunktioner og aftalte testkonti. Undgå at sende rigtige nulstillingsmails, SMS'er, bookinger eller betalte AI-kald som del af en belastningstest.

Normal brug og et harmløst dobbeltklik lykkes uden unødig ventetid eller dobbelt virkning.
Et hurtigt burst rammer den korte grænse og får et forståeligt svar uden dyrt bagvedliggende arbejde.
Mange parallelle requests beviser, at kvoten ikke kan overskrides, og at tælleren opdateres atomisk.
Samme konto fra flere IP-adresser og mange konti fra samme netværk vurderes som forskellige scenarier.
Udløbet, ugyldigt og genbrugt challenge-token bliver afvist af serveren.
En baggrundskø, mailudbyder eller ekstern API, der throttler, udløser ventetid frem for aggressive retries.
Logs og alarmer gør det muligt at skelne misbrug fra en legitim kapacitetsstigning.

Typiske fejl

Kun IP-adressen tælles: Delte netværk rammer uskyldige brugere, mens fordelte angreb fortsætter.
Samme grænse overalt: En sidevisning, en loginprøve og en betalt AI-generering har vidt forskellig risiko.
Kontrollen ligger i frontend: Et direkte request kan springe knappen, ventetiden og challenge-flowet over.
CAPTCHA ses som facit: Botkontrollen står alene uden kvoter, validering eller overvågning.
Tælleren er lokal: Hver serverinstans tillader sin egen kvote, så den samlede grænse ikke findes.
Afvisningen er dyr: Appen laver allerede database- eller leverandørkald, før den beslutter at sige nej.
Klienten retryer straks: Overbelastning vokser til en storm af skjulte gentagelser.

Tjekliste før offentlige flows åbnes

☐ Offentlige og dyre handlinger er kortlagt med mulig skade, ejer og normal brug.
☐ Hvert relevant flow har bevidste grænser for burst, længerevarende forbrug eller samtidighed.
☐ Grænsen bruger passende signaler som konto, virksomhed, session, flow og eventuelt IP – ikke kun ét let omgåeligt mål.
☐ Server, gateway eller kø håndhæver beslutningen før det dyre arbejde starter.
☐ Tællere virker på tværs af instanser og opdateres sikkert ved parallelle requests.
☐ Payload, sideantal, uploads og batchstørrelser har relevante maksimummer.
☐ HTTP 429 og eventuel Retry-After håndteres uden aggressive automatiske gentagelser.
☐ Bot- eller app-attestation valideres på serveren og står ikke alene som sikkerhedskontrol.
☐ Den normale bruger får en forståelig besked og en realistisk vej videre.
☐ Logs og alarmer viser flow, omfang, omkostning og falske positiver uden secrets.
☐ Tests dækker normal brug, bursts, parallelle requests, fordelte forsøg og downstream throttling.
☐ Et nødstop eller reduceret drift er aftalt for funktioner, der kan skabe stor skade eller regning.

Relaterede guides

API-sikkerhed, servervalidering og adgangskontrol Cloudbudget, forbrugsmål og alarmer Sikkert login, sessioner og kontogendannelse Belastningstest og kapacitetsgrænser Feature flags og nødstop Se hele guidebiblioteket

Officielle kilder

De rigtige grænser og værktøjer afhænger af appens brugere, økonomi, hosting og leverandører. Kilderne forklarer principperne og udvalgte platformfunktioner; kontrollér den aktuelle dokumentation for den stack, appen faktisk bruger.