API'er er rygraden i moderne applikationer - og den mest angrebne overflade.Over 80 % af webtrafikken flyder nu gennem API'er, og API-angreb er steget 700 % i de seneste år. API sikkerhedstest er ikke længere valgfrit – det er vigtigt for enhver organisation, der eksponerer API'er for partnere, mobilapplikationer eller internettet.
Key Takeaways
- API'er har unikke sårbarheder:OWASP API Security Top 10 dækker trusler, der er specifikke for API'er, som traditionel webtest går glip af.
- Broken Object Level Authorization (BOLA) er #1 API risikoen:Angribere manipulerer objekt-id'er i API-anmodninger for at få adgang til andre brugeres data.
- Autentificering og hastighedsbegrænsende huller er gennemgående:Mange API'er mangler korrekt token-validering, hastighedsbegrænsning og misbrugsforebyggelse.
- Automatisk + manuel test er påkrævet:Automatiserede scannere finder almindelige API-fejl. Manuel test finder forretningslogiske sårbarheder og komplekse autorisationsomgåelser.
OWASP API Sikkerhed Top 10 (2023)
| # | Sårbarhed | Beskrivelse | Testmetode |
|---|---|---|---|
| API1 | Broken Object Level Autorisation | Adgang til andre brugeres objekter ved at ændre ID'er | Test hvert endepunkt med forskellige brugertokens, opregn objekt-id'er |
| API2 | Brudt godkendelse | Svag tokengenerering, manglende validering, usikre flows | Tokenanalyse, brute force, flowmanipulation |
| API3 | Broken Object Property Level Authorization | Massetildeling, overdreven dataeksponering i svar | Tilføj uventede felter i anmodninger, analyser svardata |
| API4 | Ubegrænset ressourceforbrug | Manglende hastighedsbegrænsning, paginering eller størrelsesgrænser | Oversvømmelsestest, test af stor nyttelast, sideinddeling |
| API5 | Ødelagt funktionsniveauautorisation | Adgang til admin-slutpunkter som almindelig bruger | Test admin-slutpunkter med ikke-admin-tokens |
| API6 | Ubegrænset adgang til følsomme forretningsstrømme | Automatiseret misbrug af virksomhedsfunktionalitet | Botsimulering, automatiseret flowtest |
| API7 | Server Side Request Forgery (SSRF) | API henter angriberkontrollerede URL'er | URL-parametermanipulation, intern netværksundersøgelse |
| API8 | Sikkerhedsfejlkonfiguration | Udførlige fejl, CORS fejlkonfiguration, unødvendige metoder | Konfigurationsscanning, headeranalyse |
| API9 | Forkert lagerstyring | Forældede, udokumenterede eller skyggefulde API-endepunkter | API opdagelse, dokumentationssammenligning |
| API10 | Usikkert forbrug af API'er | Tillid til tredjeparts API-svar uden validering | Responsmanipulation, upstream API spoofing |
API Sikkerhedstestmetode
Opdagelse og dokumentationsgennemgang
Start med at kortlægge alle API-endepunkter. Sammenlign API dokumentation (OpenAPI/Swagger-specifikationer) med faktisk adfærd. Brug værktøjer som Burp Suite, Postman og brugerdefinerede scripts til at opdage udokumenterede slutpunkter. Shadow API'er - endepunkter, der eksisterer, men ikke er dokumenterede - er almindelige og mangler ofte sikkerhedskontroller, fordi de blev glemt.
Autentificeringstest
Test API-godkendelsesmekanismer: JWT-tokenvalidering (kan tokens manipuleres, forfalskes eller afspilles?), OAuth-flows (håndhæves tilstandsparameter? Kan omdirigerings-URI'er manipuleres?), API nøglestyring (er nøgler korrekt omfang? Kan de udtrækkes fra klient-side-styringskode?)
Autorisationstest
Test hvert slutpunkt med forskellige privilegieniveauer. Erstat bruger-id'er, lejer-id'er og objekt-id'er i anmodninger om at verificere adgangskontrol. Test horisontal godkendelse (bruger A, der får adgang til bruger B's data) og vertikal godkendelse (almindelig bruger, der får adgang til admin-slutpunkter). Brug automatisering til at teste alle endepunkter systematisk - manuel test alene savner endepunkter i store API'er.
Inputvalidering og injektionstest
Test alle inputparametre for injektionssårbarheder: SQL-injektion i forespørgselsparametre, NoSQL-injektion i JSON-kroppe, kommandoinjektion i behandlingsendepunkter og GraphQL-specifik injektion (indlejrede forespørgsler, introspektionsmisbrug). Test med både misdannede input (fuzzing) og omhyggeligt udformede nyttelaster rettet mod specifikke injektionstyper.
API Sikkerhedstestværktøjer
- Burp Suite:Omfattende API sikkerhedstest med proxy-, scanner- og automatiseringsfunktioner.
- Postbud:API udviklingsplatform med sikkerhedstestsamlinger og automatiserede testscripts.
- OWASP ZAP:Gratis API sikkerhedsscanner med OpenAPI import og automatiseret scanning.
- Kerner:Skabelonbaseret scanner med API-specifikke skabeloner til almindelige sårbarheder.
- Arjun:HTTP-parameteropdagelsesværktøj til at finde skjulte API-parametre.
- GraphQL Voyager:GraphQL API visualiserings- og introspektionsværktøj.
Hvordan Opsio tester API sikkerhed
- OWASP API Top 10 dækning:Hver API test dækker alle 10 kategorier med platformsspecifikke testteknikker.
- Automatiseret + manuel tilgang:Automatiseret scanning for kendte sårbarheder, manuel test for forretningslogik og komplekse godkendelsesfejl.
- GraphQL ekspertise:Specialiseret test for GraphQL API'er, herunder introspektion, indlejrede forespørgselsangreb og misbrug af batchforespørgsler.
- CI/CD integration:Vi hjælper med at integrere automatiseret API-sikkerhedstest i din implementeringspipeline for kontinuerlig sikkerhed.
Ofte stillede spørgsmål
Hvordan er API sikkerhedstest forskellig fra webapplikationstest?
Test af webapplikationer fokuserer på brugergrænsefladen og browserbaserede interaktioner. API-test er direkte målrettet mod API-laget - test af slutpunkter, parametre, godkendelsestokens og dataserialisering, som brugergrænsefladen muligvis ikke afslører. Mange sårbarheder findes kun i API-laget og kan ikke opdages alene gennem UI-test.
Skal jeg teste interne API'er eller kun offentlige-vendte?
Begge. Offentlige API'er er direkte udsat for angribere og bør testes først. Interne API'er er ofte mindre sikre, fordi udviklere antager beskyttelse på netværksniveau. Hvis en angriber får intern adgang (gennem phishing, VPN-kompromis eller fejlkonfiguration af skyen), bliver interne API'er angrebsoverfladen for lateral bevægelse og datatyveri.
Hvordan sikrer jeg specifikt GraphQL API'er?
GraphQL introducerer unikke risici: ubegrænset forespørgselsdybde (denial of service), afsløring af introspektion (skemalækage) og misbrug af batchforespørgsler (omgå hastighedsgrænser). Sikre GraphQL ved at deaktivere introspektion i produktionen, implementere forespørgselsdybde- og kompleksitetsgrænser, håndhæve autorisation pr. felt og hastighedsbegrænsning af forespørgselsomkostninger i stedet for antal anmodninger.