Adgang og sikkerhed

API-sikkerhed: beskyt appens indgange – ikke kun knapperne

En formular kan se låst og korrekt ud, mens API'et bagved stadig accepterer ekstra felter, en anden kundes id eller tusind dyre kald i træk. API-sikkerhed betyder, at serveren selv kontrollerer hver forespørgsel, begrænser arbejdet og kun sender de data tilbage, som klienten må få.

Find alle indgange til appen

Et API er ikke kun en særskilt server med /api i adressen. Det kan også være en serverless function, en webhook, en handling i et backend-framework eller en databasefunktion, som frontend kalder direkte. Kortlæg de aktive indgange før I forsøger at sikre dem.

Endpoint eller hændelse	Hvem kalder?	Data og virkning	Kontroller
`POST /orders`	Indlogget kunde	Opretter ordre og kan udløse mail	Rolle, kunde, felter, størrelse og frekvens
`PATCH /users/:id`	Bruger eller administrator	Ændrer profil eller adgang	Objekt, rolle og tilladte felter
Betalingswebhook	Betalingsudbyder	Ændrer betalingsstatus	Signatur, gentagelser og hændelses-id

Notér også miljø, version, ejer, forventet autentifikation og hvilke eksterne tjenester der modtager data. Gamle testhosts og glemte endpoints kan være lige så offentlige som den aktuelle produktion, selv om brugerfladen ikke længere linker til dem.

Valider hele forespørgslen på serveren

Kontroller i browseren gør formularen rar at bruge, men de kan omgås. Serveren skal derfor afvise ugyldig type, format, længde, interval og forretningsregel, før data bruges eller gemmes. En schema-validator kan hjælpe, men schemaet skal beskrive det, endpointet faktisk tillader – ikke bare databasens fulde model.

Syntaks: Er værdien den forventede type og inden for en fast længde eller størrelse?
Forretning: Er statusskiftet, datoen, beløbet og relationen gyldig i denne situation?
Felter: Accepter kun de felter, som klienten må ændre på netop dette endpoint.
Indholdstype og størrelse: Afvis ukendt format, for store bodies, arrays, filer og forespørgsler.

Send ikke requesten direkte ind i datamodellen. Hvis klienten må ændre displayName, skal et medsendt role, tenantId eller approved afvises eller ignoreres efter en bevidst regel. Ellers kan en ekstra egenskab få en virkning, som formularen aldrig viste.

Kontrollér både handling, objekt og svarfelter

Et gyldigt login giver ikke automatisk ret til alle endpoints eller data. Hver forespørgsel skal kontrolleres mod den konkrete handling og det konkrete objekt. Et tilfældigt eller svært gætteligt id er nyttigt, men erstatter ikke en rettighedskontrol.

Identitet: Er sessionen eller tokenet gyldigt og udstedt til denne API?
Funktion: Må rollen kalde handlingen, eksempelvis eksport eller sletning?
Objekt: Tilhører sagen, filen eller kunden den virksomhed og relation, brugeren må arbejde med?
Felt: Må brugeren læse og ændre netop disse egenskaber?
Svar: Returnerer endpointet kun de nødvendige felter – uden intern note, nulstillingstoken eller andre følsomme værdier?

Hold reglerne server-side, i databasens politikker eller i platformens Security Rules. Den praktiske model for roller, virksomheder og dataposter er beskrevet nærmere iguiden om roller og rettigheder.

CORS er en browserregel – ikke jeres login

CORS fortæller browseren, hvilke origins der må læse svar på tværs af domæner. Det stopper ikke et script, en mobilklient eller et direkte HTTP-kald fra at sende en forespørgsel til API'et. Autentifikation, autorisation og inputvalidering skal derfor virke, selv når forespørgslen ikke kommer gennem jeres egen frontend.

Tillad kendte origins: Brug en konkret liste til private browserklienter og gennemgå preview- og testdomæner.
Credentials kræver præcision: Browseren tillader ikke wildcard-origin sammen med credentialed requests; brug den konkrete origin og de nødvendige headers og metoder.
Cookie-session: Hvis browseren automatisk sender sessionscookies, skal ændrende handlinger have en passende CSRF-beskyttelse.
SameSite hjælper, men er ikke altid nok: Vælg cookie-attributter og CSRF-kontrol efter domæner, loginflow og hvilke klienter appen skal understøtte.

Sæt grænser for arbejde, omkostning og misbrug

Ét request kan udløse databaseforespørgsler, filbehandling, AI-kald, mails eller SMS. Begræns derfor ikke kun antal requests. Sæt også loft over størrelse, antal poster, samtidighed, køretid og de dyre forretningshandlinger, som endpointet kan starte.

Pr. bruger eller kunde: Forhindrer én støjende eller fejlende klient i at bruge alles kapacitet.
For hele tjenesten: Beskytter backend og eksterne leverandører, når samlet belastning bliver for høj.
For den dyre handling: Begrænser eksempelvis eksport, invitationer, filanalyse eller generering særskilt.
For request og resultat: Brug maksimum for body, fil, sideantal, query-resultat, timeout og samtidige jobs.

Når en klient sender for mange requests, kan API'et svare med HTTP 429 og eventuelt fortælle, hvornår klienten bør prøve igen. Vælg grænser ud fra normal brug, kendte leverandørgrænser og konsekvensen af at afvise – ikke et tilfældigt standardtal.

Stol heller ikke blindt på eksterne API’er

Data fra en kendt leverandør er stadig input udefra. En integration kan svare langsomt, ændre format, returnere en uventet redirect eller sende samme webhook flere gange. Behandl derfor eksterne svar med samme omhu som brugerinput.

Brug krypteret transport, opbevar leverandørens credentials server-side og giv dem mindst mulig adgang.
Sæt forbindelse- og svartimeout, begræns svarstørrelse, og validér svarets type og forventede felter.
Følg ikke redirects blindt, især ikke når requesten indeholder credentials eller følsomme data.
Planlæg retries med ventetid og et loft; gør kritiske handlinger idempotente eller registrér hændelses-id, så gentagelser ikke opretter dubletter.
Definér hvad brugeren ser, og hvad systemet gør, når leverandøren er nede eller svarer med ugyldige data.

Giv sikre svar og brugbare spor

Klienten skal have en stabil fejltype og et budskab, den kan handle på. Den behøver ikke stack trace, databasefejl, filsti, hemmelig nøgle eller detaljer om andre brugeres adgang. Gem tekniske detaljer i beskyttede logs med et request-id, så support kan finde hændelsen uden at vise interne oplysninger i API-svaret.

Log: endpoint, resultat, varighed, request-id og relevant bruger- eller tenantreference i en dataminimeret form.
Log ikke: adgangstokens, passwords, hele sessioncookies, secrets eller komplette følsomme payloads.
Alarmér: ved gentagne afvisninger, usædvanlig belastning, fejlrate eller pludselig brug af gamle endpoints.

Test API’et uden om brugerfladen

En sikkerhedskontrol skal kalde API'et direkte i et isoleret miljø. Bevis både det tilladte og det, der skal afvises, og kontrollér at afvisningen ikke har ændret data eller udløst en ekstern handling.

Uden login, med udløbet token og med token udstedt til en anden modtager.
Med en anden kundes eller brugers objekt-id og med en forbudt rolle.
Med ekstra felter som role, tenantId, pris eller godkendelsesstatus.
Med forkert type, grænseværdi, meget stor body, fil, array og sideforespørgsel.
Med mange samtidige eller gentagne kald til en dyr handling.
Fra en ikke-tilladt origin og, ved cookie-sessioner, uden den valgte CSRF-kontrol.
Med timeout, ugyldigt svar, redirect og gentaget webhook fra en simuleret leverandør.

Typiske fejl

Frontendvalidering bliver sikkerhed: API'et accepterer stadig requesten, når nogen omgår formularen.
Hele objektet gemmes: Ekstra felter fra klienten kan ændre rolle, ejer, pris eller status.
Et svært id betragtes som adgangskontrol: En bruger får data, hvis vedkommende finder eller modtager et gyldigt id.
CORS sættes til alt for at fjerne en fejl: Den tiltænkte browsergrænse forsvinder, mens API'ets egentlige kontroller stadig mangler.
Rate limit er ét globalt requesttal: Dyre handlinger, store svar og en enkelt støjende kunde beskyttes ikke passende.
Integrationens svar anses som sikkert: Uventede felter, redirects, størrelser og svartider får lov at flyde videre.
Gamle endpoints glemmes: Test- eller beta-versionen peger stadig på rigtige data med svagere beskyttelse.
Fejlsvaret viser for meget: Stack traces, SQL-fejl eller adgangsdetaljer hjælper uvedkommende med at kortlægge systemet.

Tjekliste før medarbejdere eller kunder får adgang

☐ Alle API-hosts, functions, webhooks, endpoints, miljøer og aktive versioner er kortlagt.
☐ Hvert endpoint har en ejer og beskriver klient, autentifikation, data, sideeffekt og grænser.
☐ Input valideres på serveren for type, format, længde, interval og forretningsregel.
☐ Kun udtrykkeligt tilladte inputfelter kan ændres, og kun nødvendige svarfelter returneres.
☐ Hver handling kontrollerer funktion, rolle, tenant, objekt og relevante feltrettigheder.
☐ CORS tillader kun de nødvendige origins, metoder og headers; det bruges ikke som login.
☐ Cookie-baserede ændringer har en dokumenteret CSRF-beskyttelse.
☐ Requeststørrelse, upload, resultatmængde, timeout, samtidighed og dyre handlinger har passende grænser.
☐ Eksterne API-svar valideres, har timeouts og størrelsesgrænser og følges ikke blindt gennem redirects.
☐ Retries og gentagne webhooks kan ikke utilsigtet udføre samme forretningshandling flere gange.
☐ Fejlsvar skjuler interne detaljer, mens logs kan findes via request-id uden at gemme secrets.
☐ Negative API-tests beviser afslag uden at ændre data eller udløse en ekstern handling.
☐ Gamle endpoints og versioner har en ejer, samme relevante beskyttelse og en plan for lukning.

Relaterede guides

Roller og rettigheder for funktioner og data API-nøgler, secrets og rotation Teststrategi for kritiske brugerrejser Logning, alarmer og overvågning Se hele guidebiblioteket

Officielle kilder

Konkrete middleware-funktioner, gateways og platformgrænser afhænger af appens stack. Brug den eksisterende platforms aktuelle dokumentation, og test kontrollerne mod den faktiske API – ikke kun mod eksemplerne i denne guide.