Bakom varje app, integration och AI-agent finns numera ett API. Och precis där affärslogiken exponeras har angriparna flyttat in. När fler system pratar maskin-till-maskin blir API-lagret den mest attackerade ytan i moderna arkitekturer – samtidigt som det ofta är sämst skyddat. Den här guiden går igenom det som faktiskt spelar roll 2026: autentisering, rate limiting, validering, OWASP:s riskbild, hantering av hemligheter och loggning. Sist får du en konkret checklista.

Autentisering och auktorisering – grunden allt vilar på

De allra flesta allvarliga API-incidenter handlar inte om exotiska kryptosårbarheter, utan om något betydligt tråkigare: bristande åtkomstkontroll. Det är värt att internalisera innan vi går vidare.

OAuth 2.1 är den nya normen

För användarinloggning och delegerad åtkomst är OAuth 2.0 fortfarande ryggraden, men riktningen är tydlig. OAuth 2.1 är i juni 2026 ännu ett IETF-utkast (draft-ietf-oauth-v2-1) snarare än en färdig RFC, men dess rekommendationer behandlas redan som de facto-standard av samtliga större identitetsleverantörer. De viktigaste skärpningarna att rätta sig efter:

  • PKCE krävs för alla authorization code-flöden – även för konfidentiella klienter, inte bara publika. Det stänger igen avlyssning av auktoriseringskoder.

  • Implicit grant och Resource Owner Password Credentials är borttagna. Använder du fortfarande dessa flöden är det dags att migrera.

  • Tokens får aldrig ligga i query-strängar. Access tokens hör hemma i Authorization-headern eller i request-body – aldrig i URL:en, där de hamnar i loggar och referrers.

  • Exakt strängmatchning av redirect-URI:er i stället för wildcard-jämförelser.

För single page-appar gäller authorization code-flödet med PKCE, access tokens i minnet (inte i localStorage) och refresh tokens i HttpOnly-cookies. För maskin-till-maskin-integrationer används client credentials-flödet, gärna kompletterat med sender-constrained tokens via DPoP eller mTLS så att en stulen token är värdelös på en annan klient.

API-nycklar har sin plats – men kan inte bära autentisering ensam

API-nycklar är utmärkta för att identifiera vilken klient eller integration ett anrop kommer från, och för att knyta kvoter och fakturering till en konsument. Men en API-nyckel är en statisk hemlighet: den bevisar inte vem användaren är och kan inte begränsa vad som får göras. Använd nycklar för identifiering och routing, men lägg den egentliga auktoriseringen på OAuth-scopes, tokens med kort livslängd och kontroller på objektnivå.

Auktorisering på objektnivå – det vanligaste hålet

Den enskilt största riskklassen i API-världen är att ett anrop får komma åt objekt som det inte borde. Det räcker inte att kontrollera att användaren är inloggad – du måste kontrollera att just den användaren har rätt till just det objektet, vid varje anrop. Ett klassiskt misstag är att lita på ett id i URL:en (/api/orders/12345) utan att verifiera ägarskap. Validera alltid behörighet mot den autentiserade identiteten i backend, aldrig mot något klienten skickar med.

OWASP API Security Top 10 – riskbilden 2026

Den auktoritativa kartan över API-risker är OWASP API Security Top 10, vars 2023-utgåva fortfarande är den gällande stabila versionen i juni 2026. Den är värd att läsa i sin helhet, men huvudbudskapet är glasklart: tre av de fem översta riskerna handlar om bristande auktorisering.

  • Broken Object Level Authorization (BOLA) – åtkomst till andras objekt, listans tyngsta post.

  • Broken Authentication – svaga eller felimplementerade inloggningsflöden.

  • Broken Object Property Level Authorization – exponering eller manipulation av enskilda fält användaren inte borde se eller ändra.

  • Unrestricted Resource Consumption – avsaknad av kvoter och gränser, det som rate limiting adresserar.

  • Broken Function Level Authorization – att vanliga användare når administrativa endpoints.

Nytt i 2023-utgåvan jämfört med 2019 är bland annat Server Side Request Forgery (SSRF) och Unrestricted Access to Sensitive Business Flows – den senare fångar missbruk som scalping av lagervaror och massregistrering av falska konton, alltså attacker mot affärslogik snarare än mot kod.

Rate limiting – din första försvarslinje

Utan kvoter kan en angripare översvämma ditt API med anrop tills det blir oåtkomligt för riktiga användare. Rate limiting är ett basskydd mot DDoS, credential stuffing och brute force – och samtidigt ett sätt att hålla kostnader och prestanda under kontroll.

Det finns flera algoritmer och valet beror på trafikmönstret:

  • Token bucket tillåter korta toppar samtidigt som ett snitt hålls över tid. Populärt hos betal-API:er och publika utvecklarplattformar där burst är normalt.

  • Sliding window counter är ett bra standardval för de flesta produktions-API:er – rättvis och exakt begränsning med låg minnesåtgång.

  • Fixed window och leaky bucket har sina nischer men medför antingen kant-effekter eller mindre flexibilitet vid toppar.

I praktiken: lägg begränsningen i din API-gateway eller i middleware, använd en delad Redis-instans för att hålla räknarstate i en distribuerad miljö, och returnera alltid standardiserade headers (RateLimit-Limit, RateLimit-Remaining, Retry-After) så att välartade klienter kan styra sig själva. Differentiera gärna gränserna per identitet och per endpoint – inloggning och andra känsliga flöden ska ha strängare tak än läsanrop.

Validering – lita aldrig på indata

Allt som kommer utifrån är opålitligt tills motsatsen bevisats. Robust indatavalidering stänger igen en lång rad sårbarheter, från injektioner till logiska fel.

  • Validera mot schema. Definiera dina API:er med OpenAPI och validera varje request mot kontraktet – typer, format, obligatoriska fält, längder och tillåtna värden.

  • Positiv validering (allowlist) framför att försöka filtrera bort det onda. Tillåt det du känner igen, avvisa allt annat.

  • Bind inte indata blint till dina objekt. Mass assignment, där en klient skickar med fält som isAdmin eller role, är en återkommande väg in. Ange explicit vilka fält som får sättas.

  • Begränsa storlek och djup på payloads och nästlade strukturer för att undvika resursutmattning.

  • Validera även det du anropar utåt. Vid SSRF-risk: tillåt bara anrop till kända, listade destinationer.

Hemligheter – ut ur koden, in i ett valv

Läckta API-nycklar, databaslösenord och tokens hör till de vanligaste orsakerna till intrång. OWASP:s vägledning för secrets management är tydlig och bör vara din ledstjärna:

  • Aldrig hemligheter i källkod eller i versionshistoriken. Skanna repos och CI-pipelines efter läckta nycklar.

  • Centralisera i en dedikerad hemlighetshanterare – HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager eller Azure Key Vault. De ger åtkomstkontroll, revisionsloggar och rotation på ett ställe.

  • Behandla hemligheter som flyktiga. Korta livslängder och automatisk rotation utan kodutrullning. Vaults dynamiska secrets kan exempelvis generera databasinloggning med en TTL och återkalla den automatiskt när tiden gått ut.

  • Finkornig åtkomst. Varje tjänst ska bara komma åt de hemligheter den faktiskt behöver – behörighet på hemlighetsnivå framför breda valv- eller projektpolicyer.

  • Rotera utan stillestånd med ett dubbelnyckelmönster där både gammal och ny credential är giltig under en kort överlappning.

Loggning och övervakning – se attacken medan den pågår

Otillräcklig loggning förlänger tiden innan ett intrång upptäcks från minuter till månader. Även om loggning inte längre står som egen punkt i OWASP API Top 10 är det avgörande för att kunna upptäcka och utreda de övriga riskerna.

  • Logga säkerhetsrelevanta händelser – misslyckade inloggningar, auktoriseringsfel, anrop som överskrider kvoter, oväntade statuskoder.

  • Maskera känsliga data. Tokens, lösenord och personuppgifter ska aldrig hamna i klartext i loggarna – det skapar bara en ny måltavla, och vid personuppgifter en GDPR-risk.

  • Centralisera och larma. Samla loggar i ett SIEM eller motsvarande och sätt upp larm på anomalier som plötsliga toppar i 401/403 eller misstänkt enumeration av objekt-id.

  • Korrelera över hela kedjan med spårnings-id så att ett anrop kan följas genom alla tjänster.

Checklista för företag med integrationer

  • Inventera alla API:er, inklusive interna och bortglömda (shadow- och zombie-API:er).

  • Autentisera med OAuth 2.1-principer: PKCE, inga implicit-flöden, tokens med kort livslängd.

  • Kontrollera behörighet på objektnivå vid varje anrop – aldrig bara att användaren är inloggad.

  • Sätt rate limiting per identitet och endpoint i din gateway, med standardiserade headers.

  • Validera all indata mot OpenAPI-schema och använd allowlist samt explicit fältbindning.

  • Flytta alla hemligheter till ett valv med automatisk rotation och finkornig åtkomst.

  • Logga säkerhetshändelser, maskera känsliga fält och larma på anomalier.

  • Testa kontinuerligt – automatiserad API-säkerhetstestning i CI och regelbunden penetrationstestning.

  • Stäm av mot OWASP API Security Top 10 som återkommande genomgång.

Bygg säkert från början

API-säkerhet är inget man bygger på i efterhand utan en kvalitet som vävs in i arkitektur, kodbas och drift. Det billigaste tillfället att göra rätt är innan integrationen byggs – det dyraste är efter ett intrång. På ZORC bygger vi integrationer och API:er med de här principerna inbyggda från dag ett, och hjälper gärna till att granska en befintlig lösning. Vill du veta vad ett säkerhetsgranskat API- eller integrationsprojekt skulle innebära för er kostar det ingenting att fråga – berätta om ert behov i offertkalkylatorn eller hör av dig via kontakt.