API: er är ryggraden i moderna applikationer – och den mest attackerade ytan.Över 80 % av webbtrafiken flödar nu genom API:er och API-attacker har ökat med 700 % de senaste åren. API säkerhetstestning är inte längre valfritt – det är viktigt för alla organisationer som exponerar API:er för partners, mobilapplikationer eller internet.
Nyckel takeaways
- API:er har unika sårbarheter:OWASP API Security Top 10 täcker hot som är specifika för API:er som traditionella webbtester missar.
- Broken Object Level Authorization (BOLA) är #1 API-risken:Angripare manipulerar objekt-ID:n i API-förfrågningar för att komma åt andra användares data.
- Autentisering och hastighetsbegränsande luckor är genomgående:Många API:er saknar korrekt tokenvalidering, hastighetsbegränsning och förhindrande av missbruk.
- Automatisk + manuell testning krävs:Automatiserade skannrar hittar vanliga API-brister. Manuell testning hittar sårbarheter i affärslogik och komplexa auktoriseringsförbikopplingar.
OWASP API Säkerhet Topp 10 (2023)
| # | Sårbarhet | Beskrivning | Testmetod |
|---|---|---|---|
| API1 | Broken Object Level Authorization | Åtkomst till andra användares objekt genom att ändra ID:n | Testa varje slutpunkt med olika användartokens, räkna upp objekt-ID:n |
| API2 | Trasig autentisering | Svag tokengenerering, saknad validering, osäkra flöden | Tokenanalys, brute force, flödesmanipulation |
| API3 | Broken Object Property Level Authorization | Masstilldelning, överdriven dataexponering i svar | Lägg till oväntade fält i förfrågningar, analysera svarsdata |
| API4 | Obegränsad resursförbrukning | Saknar hastighetsbegränsning, paginering eller storleksgränser | Översvämningstestning, testning av stor nyttolast, sideringsförbikoppling |
| API5 | Trasig funktionsnivå auktorisering | Åtkomst till adminslutpunkter som vanlig användare | Testa admin-slutpunkter med icke-admin-tokens |
| API6 | Obegränsad tillgång till känsliga affärsflöden | Automatiserat missbruk av affärsfunktioner | Botsimulering, automatiserad flödestestning |
| API7 | Server Side Request Forgery (SSRF) | API hämtar angriparkontrollerade webbadresser | URL-parametermanipulation, intern nätverksundersökning |
| API8 | Säkerhetsfelkonfiguration | Utförliga fel, CORS-felkonfiguration, onödiga metoder | Konfigurationsskanning, rubrikanalys |
| API9 | Felaktig lagerhantering | Utfasade, odokumenterade eller skuggade API-slutpunkter | API upptäckt, dokumentationsjämförelse |
| API10 | Osäker konsumtion av API:er | Att lita på tredje parts API-svar utan validering | Svarsmanipulering, uppströms API spoofing |
API Säkerhetstestmetod
Upptäckt och dokumentationsgranskning
Börja med att kartlägga alla API slutpunkter. Jämför API dokumentation (OpenAPI/Swagger-specifikationer) med faktiska beteenden. Använd verktyg som Burp Suite, Postman och anpassade skript för att upptäcka odokumenterade slutpunkter. Shadow API:er – slutpunkter som finns men inte är dokumenterade – är vanliga och saknar ofta säkerhetskontroller eftersom de glömdes bort.
Autentiseringstestning
Testa API autentiseringsmekanismer: JWT-tokenvalidering (kan tokens manipuleras, förfalskas eller spelas upp igen?), OAuth-flöden (tillståndsparameter verkställs? Kan omdirigerings-URI:er manipuleras?), API nyckelhantering (är nycklar korrekt omfång? Kan de extraheras från klientens hanteringskod?)
Behörighetstestning
Testa varje slutpunkt med olika behörighetsnivåer. Ersätt användar-ID, klient-ID och objekt-ID i förfrågningar för att verifiera åtkomstkontroller. Testa horisontell auktorisering (användare A får åtkomst till användare B:s data) och vertikal auktorisering (vanlig användare som får åtkomst till adminslutpunkter). Använd automatisering för att systematiskt testa alla slutpunkter – enbart manuell testning missar slutpunkter i stora API:er.
Ingångsvalidering och injektionstestning
Testa alla inmatningsparametrar för injektionssårbarheter: SQL injektion i frågeparametrar, NoSQL injektion i JSON kroppar, kommandoinjektion i bearbetningsslutpunkter och GraphQL-specifik injektion (kapslade frågor, introspektionsmissbruk). Testa med både felformade ingångar (fuzzing) och noggrant utformade nyttolaster riktade mot specifika injektionstyper.
API Säkerhetstestverktyg
- Burp Suite:Omfattande API säkerhetstestning med proxy-, skanner- och automationsfunktioner.
- Brevbärare:API utvecklingsplattform med säkerhetstestsamlingar och automatiserade testskript.
- OWASP ZAP:Gratis API säkerhetsskanner med OpenAPI-import och automatisk skanning.
- Kärnor:Mallbaserad skanner med API-specifika mallar för vanliga sårbarheter.
- Arjun:HTTP-parameterupptäcktsverktyg för att hitta dolda API-parametrar.
- GraphQL Voyager:GraphQL API visualiserings- och introspektionsverktyg.
Hur Opsio testar API Säkerhet
- OWASP API Topp 10 täckning:Varje API-test täcker alla 10 kategorier med plattformsspecifika testtekniker.
- Automatiserad + manuell inställning:Automatisk genomsökning efter kända sårbarheter, manuell testning av affärslogik och komplexa auktoriseringsbrister.
- GraphQL expertis:Specialiserade tester för GraphQL API:er inklusive introspektion, kapslade frågeattacker och missbruk av batchfrågor.
- CI/CD integration:Vi hjälper till att integrera automatiserade API säkerhetstester i din distributionspipeline för kontinuerlig säkerhet.
Vanliga frågor
Hur skiljer sig API säkerhetstestning från webbapplikationstestning?
Testning av webbapplikationer fokuserar på användargränssnittet och webbläsarbaserade interaktioner. API-testning riktar sig direkt mot lagret API — testning av slutpunkter, parametrar, autentiseringstokens och dataserialisering som gränssnittet kanske inte exponerar. Många sårbarheter finns bara i API-lagret och kan inte upptäckas enbart genom UI-testning.
Ska jag testa interna API:er eller bara offentliga?
Både. Offentliga API:er är direkt exponerade för angripare och bör testas först. Interna API:er är ofta mindre säkra eftersom utvecklare antar skydd på nätverksnivå. Om en angripare får intern åtkomst (genom nätfiske, VPN-kompromiss eller felkonfiguration av molnet) blir interna API:er attackytan för sidoförflyttning och datastöld.
Hur säkrar jag GraphQL API:er specifikt?
GraphQL introducerar unika risker: obegränsat frågedjup (denial of service), avslöjande av introspektion (schemaläckage) och missbruk av gruppförfrågningar (förbigående av hastighetsgränser). Säkra GraphQL genom att inaktivera introspektion i produktionen, implementera gränser för frågedjup och komplexitet, upprätthålla auktorisering per fält och hastighetsbegränsning av frågekostnad snarare än antal begäranden.