{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/api-security","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/api-security/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/api-security/"},"term":{"en":"API security","da":"API-sikkerhed"},"aka":{"en":[],"da":[]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","era":2019,"summary":{"en":"Protecting the APIs that programs use to talk to each other, so each caller can reach and change only what it is allowed to.","da":"Beskyttelse af de API'er, som programmer taler sammen igennem, så hver kalder kun kan se og ændre det, den har lov til."},"body":{"formal":{"en":"The set of controls that guard an API - authentication of every caller, authorization checked per object and per action, limits on how often and how much can be requested, input validation and an up-to-date list of every API in use.","da":"De kontroller, der beskytter et API - autentificering af hver kalder, autorisation tjekket for hvert objekt og hver handling, grænser for, hvor ofte og hvor meget der kan hentes, inputvalidering og en opdateret liste over alle API'er i brug."},"plain":{"en":"Like a bank cashier who checks not only who you are but also that the account you ask about is really yours - every single time.","da":"Som en kasserer i banken, der ikke kun tjekker, hvem du er, men også at den konto, du spørger til, faktisk er din - hver eneste gang."},"inPractice":{"en":"A municipality's citizen app asks its API for case 1001, which belongs to the logged-in citizen; a curious user changes the number to 1002 and sees a neighbour's case, because the API checked the MitID login but not who owns the case.","da":"En kommunes borgerapp beder sit API om sag 1001, der tilhører den indloggede borger; en nysgerrig bruger ændrer tallet til 1002 og ser naboens sag, fordi API'et tjekkede MitID-login, men ikke hvem sagen tilhører."},"whyItMatters":{"en":"Apps, partners and AI agents increasingly reach data through APIs rather than web pages, so one missing ownership check can expose every record in a system at once.","da":"Apps, samarbejdspartnere og AI-agenter henter i stigende grad data gennem API'er frem for websider, så ét manglende ejerskabstjek kan udstille alle poster i et system på én gang."}},"deepDive":{"en":"API security differs from classic web security because an API exposes the application's object model directly: identifiers, field names and operations arrive as structured parameters that a client can enumerate and replay at machine speed, with no user interface to hide anything. The OWASP API Security Top 10 (2023) reflects this. Its first entry, API1 Broken Object Level Authorization (BOLA, the API name for IDOR), is the case where the server authenticates the caller but never checks that the object ID in the path or body belongs to them. API3 Broken Object Property Level Authorization covers both excessive data exposure (returning every column and filtering in the client) and mass assignment (binding an incoming JSON body straight onto a model so a caller can set fields such as isAdmin or ownerId). API5 Broken Function Level Authorization is the same failure one level up, for example a regular user calling an administrative DELETE endpoint.\n\nAuthentication for machine clients is usually OAuth 2.0 access tokens, often JWTs, or mutual TLS. Common failures are accepting unsigned tokens (alg none), not validating aud, iss and exp, confusing RS256 with HS256 so a public key is used as an HMAC secret, and long-lived bearer tokens with no binding to the client. Sender-constrained tokens (mTLS-bound per RFC 8705, or DPoP per RFC 9449) reduce the value of a stolen token. API keys identify a client application; on their own they do not authenticate a user.\n\nResource controls address API4 Unrestricted Resource Consumption and API6 Unrestricted Access to Sensitive Business Flows: rate limits per identity rather than per IP, maximum page sizes, request body limits, timeouts and, for GraphQL, query depth and cost limits plus disabled introspection in production. API9 Improper Inventory Management is the shadow and zombie API problem: old versions such as /v1 that stay reachable without the fixes applied to /v2. An OpenAPI description kept in the build pipeline gives both an inventory and a schema that a gateway can enforce.\n\nAn API gateway or WAF is good at coarse controls (TLS termination, token validation, quotas, schema checks), but it cannot know whether user 17 owns invoice 4711. Object-level authorization therefore has to live in the service, ideally in one central policy layer, and has to be tested with two accounts, since scanners that use one identity rarely find BOLA. NIST SP 800-228 frames the same controls for cloud-native, service-to-service APIs, where east-west traffic between microservices needs authentication just as much as the public edge.","da":"API-sikkerhed adskiller sig fra klassisk websikkerhed, fordi et API eksponerer applikationens objektmodel direkte: id'er, feltnavne og operationer kommer ind som strukturerede parametre, som en klient kan gennemløbe og afspille igen i maskintempo, uden en brugerflade, der skjuler noget. OWASP API Security Top 10 (2023) afspejler det. Første punkt, API1 Broken Object Level Authorization (BOLA, API-verdenens navn for IDOR), er situationen, hvor serveren autentificerer kalderen, men aldrig tjekker, at objekt-id'et i stien eller body'en tilhører vedkommende. API3 Broken Object Property Level Authorization dækker både overeksponering af data (hele rækken returneres, og klienten filtrerer) og mass assignment (en indkommende JSON-body bindes direkte på en model, så kalderen kan sætte felter som isAdmin eller ownerId). API5 Broken Function Level Authorization er samme fejl et niveau op, fx en almindelig bruger, der kalder et administrativt DELETE-endpoint.\n\nAutentificering af maskinklienter sker typisk med OAuth 2.0-access tokens, ofte JWT'er, eller med gensidig TLS. Klassiske fejl er at acceptere usignerede tokens (alg none), ikke at validere aud, iss og exp, at forveksle RS256 med HS256, så en offentlig nøgle bruges som HMAC-hemmelighed, og langlivede bearer tokens uden binding til klienten. Afsenderbundne tokens (mTLS-bundne efter RFC 8705 eller DPoP efter RFC 9449) gør et stjålet token mindre værd. En API-nøgle identificerer en klientapplikation; alene autentificerer den ikke en bruger.\n\nRessourcekontroller rammer API4 Unrestricted Resource Consumption og API6 Unrestricted Access to Sensitive Business Flows: rate limits pr. identitet frem for pr. IP-adresse, maksimal sidestørrelse, grænser for body-størrelse, timeouts og for GraphQL grænser for forespørgselsdybde og -omkostning samt slået introspection fra i produktion. API9 Improper Inventory Management er problemet med skygge- og zombie-API'er: gamle versioner som /v1, der stadig kan nås uden de rettelser, der er lavet i /v2. En OpenAPI-beskrivelse, der vedligeholdes i build-pipelinen, giver både et inventar og et skema, som en gateway kan håndhæve.\n\nEn API-gateway eller WAF er god til grove kontroller (TLS-terminering, tokenvalidering, kvoter, skematjek), men den kan ikke vide, om bruger 17 ejer faktura 4711. Autorisation på objektniveau skal derfor ligge i selve tjenesten, helst i ét centralt politiklag, og den skal testes med to konti, fordi scannere med én identitet sjældent finder BOLA. NIST SP 800-228 beskriver de samme kontroller for cloud-native API'er mellem tjenester, hvor øst-vest-trafik mellem microservices kræver autentificering lige så meget som den offentlige kant."},"edges":[{"type":"requires","to":"cs/api","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/authorization","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/data-breach","why":{"en":"Checking who may reach each record stops callers from pulling data that belongs to others.","da":"Når der tjekkes, hvem der må se hver post, kan kaldere ikke hente data, der tilhører andre."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"security/web-application-firewall","why":{"en":"A WAF or API gateway in front filters and limits traffic, while the checks on who owns what live in the API itself.","da":"En WAF eller en API-gateway foran filtrerer og begrænser trafikken, mens tjekket af, hvem der ejer hvad, ligger i selve API'et."},"confidence":"medium","strength":"normal"}],"depth":5,"sources":[{"title":"OWASP API Security Top 10 (2023)","url":"https://owasp.org/API-Security/editions/2023/en/0x11-t10/","tier":"reference","publisher":"OWASP"},{"title":"NIST SP 800-228 - Guidelines for API Protection for Cloud-Native Systems","url":"https://csrc.nist.gov/pubs/sp/800/228/upd1/final","tier":"standard","publisher":"NIST"}],"draft":true}