När jag arbetar med API-säkerhet försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. API-säkerhet måste kontrollera både vem klienten är och om just den identiteten får agera på just det objekt som begärs.
API-säkerhet i praktiken
Första byggstenen: Autentisering och objektbehörighet är separata kontroller. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Rate limiting begränsar missbruk men ersätter inte auktorisering. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Inputvalidering bör ske mot ett tydligt schema. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Audit logs behöver fånga säkerhetsrelevanta ändringar utan att lagra känsliga tokens. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Skriv en resurs- och behörighetsmatris.
- Validera varje object id mot användarens scope eller ägarskap.
- Använd schema för request och response.
- Begränsa dyra endpoints separat.
- Testa samma request med lägre privilegierad identitet.
För API-säkerhet håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
Ett klassiskt negativt test är att autentisera som användare A och ändra ett numeriskt objekt-id till ett som tillhör användare B. Ett korrekt API ska stoppa detta även om båda objekten finns.
Fallgropar jag försöker undvika
- Att kontrollera roll i UI men inte i API.
- Att anta att ett oförutsägbart ID är en säkerhetskontroll.
- Att returnera för mycket data i felmeddelanden.
Kontrollpunkter
För API-säkerhet vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- User A kan inte läsa user B:s objekt.
- Rate limit ger förutsägbart svar utan att krascha tjänsten.
- Ändringar kan spåras till en unik identitet.
Ett negativt test hör också till API-säkerhet: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
API-säkerhet – autentisering, objektbehörighet, rate limiting och loggning handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.