API-beveiligingstesten: een Complete Gids

Uw bestaande controles bewijzen waarschijnlijk één ding goed: dat de service zich correct gedraagt voor iedereen die de regels volgt. Of het ook degenen weert die dat niet doen, is een andere vraag, en een die de meeste releasecycli nooit bereiken. API-beveiligingstesten bekijken of iemand die al weet hoe hij met uw endpoints moet praten, ze kan laten misdragen.

Het onderzoekt hoe u logins en tokens afhandelt, of elk verzoek mag doen wat het vraagt, hoeveel verkeer u toestaat, en wat uw reacties prijsgeven. Dit werk heeft zijn eigen risicolijst, de OWASP API Security Top 10. Dat is niet hetzelfde als de algemene webapplicatieversie die de meeste checklists volgen.

Drie van de tien API-risico’s zijn autorisatiefouten, waarbij de service precies weet wie er vraagt en toch records overhandigt die aan iemand anders toebehoren. Een webapplicatie-checklist stopt dat allemaal in één brede categorie. Wij zoeken naar die fouten tijdens de dagelijkse QA, en voeren penetratietestdiensten uit wanneer een release een diepere, afgebakende review vereist.

De rest van deze gids gaat over hoe u elk daarvan controleert.

Hoe API-beveiligingstesten Verschillen van Webapp-beveiligingstesten

Beveiligingstesten voor webapplicaties gaan uit van een persoon in een browser. Iemand vult een formulier in, verzendt het, en het scherm bepaalt wat hem getoond wordt. Daarom leeft veel van de bescherming op die pagina: velden die u niet kunt bewerken, knoppen die u nooit ziet, menu’s die alles verbergen wat u niet zou mogen bereiken.

Een API heeft daar niets van. Ze antwoordt aan wie dan ook een correct geformuleerd verzoek stuurt, en de aanroeper is meestal een script in plaats van een persoon. Wat is API-beveiligingstesten dan in de praktijk? Het is het werk om te bewijzen dat uw API de verzoeken weigert die hij zou moeten weigeren, zelfs als ze afkomstig zijn van een account dat succesvol is ingelogd.

Dit is de verschuiving die teams verrast. Klassiek webtesten besteedt het meeste van zijn inspanning aan het buitenhouden van vreemden. Bij een API gaat u daarentegen uit van de tegenovergestelde premisse: de aanroeper heeft al een geldig token. De interessante vraag is niet meer hoe hij daar kwam, maar hoever hij nu kan reiken nu hij het heeft.

Dat heeft twee praktische gevolgen:

• Uw bedrijfslogica ligt bloot in plaats van verpakt in een interface, dus een front-end controle beschermt niets.
• Een script kan een enkel verzoek duizenden keren per minuut herhalen, wat een kleine misser omzet in een grote.

De twee OWASP-lijsten weerspiegelen deze opsplitsing. Aan de webapplicatiekant is gebroken toegangscontrole één enkel item dat alles dekt van een verborgen adminpagina tot een gemanipuleerde record-ID. De API-versie splitst hetzelfde terrein op in drie afzonderlijke risico’s, omdat die fouten er hier anders uitzien en zich anders gedragen. Voor het web-equivalent behandelt onze checklist voor webpenetratietesten het, terwijl onze beveiligingstesten-praktijk beide oppervlakken dekt.

Wat Is de OWASP API Security Top 10?

De OWASP API Security Top 10 is de referentie voor dit werk, momenteel in de editie van 2023. Beveiligingstesten van API-endpoints volgen deze meestal nauwgezet, omdat elk item een fout benoemt die u kunt gaan controleren in plaats van een principe om in gedachten te houden.

Eén naamgevingskwestie is het vermelden waard. Als u heeft gelezen over “buitensporige gegevensblootstelling” als API-risico, dat was het derde item van de editie 2019. Het werd samengevoegd tot API3 tijdens de herziening van 2023, dus de oudere term duikt nog steeds op in artikelen en tools terwijl de huidige lijst het anders noemt.

De Drie Manieren waarop API-autorisatie Faalt

Deze items beschrijven dezelfde onderliggende fout op verschillende schalen. Samen zijn ze waar de meeste echte API-incidenten beginnen, en ze verklaren waarom dit risicoprofiel niet zomaar een webapplicatie-checklist kan erven.

• API1, objectniveau. Uw API identificeert de aanroeper, en vraagt vervolgens niet of hij eigenaar is van het specifieke record dat hij opvroeg. Bijvoorbeeld, een opzoeking voor factuur 1041 lukt, dus iemand probeert 1042 en ontvangt de rekening van een vreemde. Het vinden ervan is ongepolijst en effectief: log in als de ene klant, verzamel de identifiers die u legitiem bezit, vraag dan de identifiers op die u niet heeft en kijk wat terugkomt. Een correcte API antwoordt met een weigering. De kwetsbare geeft gegevens vrij.
• API3, eigenschapniveau. Hier behoort het record wel aan u toe, maar de uitwisseling bevat meer dan zou moeten in de ene of de andere richting. Een klantprofiel zou een interne risicoscore of een reset-token kunnen retourneren naast naam en adres, omdat het endpoint het hele object verzendt en erop vertrouwt dat de app slechts een deel toont. Het omgekeerde gebeurt ook, waarbij een update een veld zoals role of account_balance accepteert dat geen enkele client zou moeten kunnen instellen. Beide richtingen hebben tests nodig, want een reactie die de app nooit weergeeft, heeft uw server toch verlaten.
• API5, functieniveau. Deze keer is de operatie buiten bereik in plaats van het record. Een standaardaccount roept de route van een beheerder aan en het werkt, omdat er niets achter is dat opnieuw controleert wie er vraagt. Op een website blijft een adminscherm verborgen voor de navigatie en meestal vergeten. Een API heeft geen menu, dus elke bevoorrechte actie heeft zijn eigen bewaking nodig, en elke moet worden geprobeerd vanuit een gewoon account.

Merk op wat de drie gemeen hebben: er is niets ingebroken. Elk verzoek was correct geformuleerd, correct geauthenticeerd, en beantwoord precies zoals de code bedoelde. Daarom overleven ze functionele tests zo comfortabel, en daarom vereist het opsporen ervan een testgeval dat opzettelijk om iets vraagt dat het niet zou moeten ontvangen.

Wat te Controleren voor de Overige Zeven Risico's

Deze blijven van belang, hoewel elk minder uitwerking nodig heeft.

• API2, authenticatie. Bekijk hoe tokens worden uitgegeven, hoe lang ze geldig blijven, of er een nog werkt na uitloggen, en of een wachtwoordreset-flow achterwaarts kan worden doorlopen.
• API4, resourceverbruik. Stuur meer verkeer dan een echte client zou doen, te grote payloads, en query’s waarvan u weet dat ze duur zijn. U wilt een duidelijke weigering in plaats van een langzame instorting.
• API6, bedrijfsprocessen. Vraag u af wat een concurrent of doorverkoper zou kunnen doen met onbeperkte geautomatiseerde toegang tot een functie die correct werkt. Ticketaankoop en het inwisselen van vouchers zijn de gebruikelijke voorbeelden.
• API7, request forgery. Overal waar uw API een webadres accepteert, richt het op interne infrastructuur en kijk of het gehoorzaamt.
• API8, configuratie. Praatgrage fouten, ontbrekende headers, en regels die elke website uw API laten aanroepen leven allemaal hier. Onze uitleg over beveiligingsconfiguratiefouten behandelt het patroon dieper.
• API9, inventaris. Ontdek wat nog bereikbaar is. Oude versies, staging-routes, en endpoints die ontbreken in de documentatie zijn gebruikelijk, en wat niemand onderhoudt, wordt ook niet gepatcht.
• API10, onveilige consumptie. Behandel gegevens die van externe diensten binnenkomen met hetzelfde wantrouwen dat u toepast op gebruikersinvoer, want een vertrouwde integratie kan u toch iets misvormds sturen.

Hoe REST, GraphQL, gRPC, en SOAP Veranderen wat U Test

De OWASP-lijst is bewust protocolneutraal, wat helpt bij planning en tekortschiet bij uitvoering. API-beveiligingstesten moeten rekening houden met hoe uw dienst daadwerkelijk communiceert, want hetzelfde risico duikt op een andere plek op, afhankelijk van de onderliggende technologie.

REST en GraphQL

REST is waar objectniveau-autorisatie het vaakst misgaat, om structurele in plaats van culturele redenen. Een REST-adres benoemt het ding waar u om vraagt, dus de identifier ligt daar zo klaar om bewerkt te worden. Niets aan de stijl maakt het minder veilig, maar het maakt één specifieke fout ongewoon gemakkelijk te maken en eenvoudig te vinden. De uitgebreide versie van die controle hoort thuis in een REST-specifieke beveiligingschecklist.

GraphQL verplaatst de blootstelling ergens anders naartoe. Omdat de client zijn eigen query samenstelt, kan een enkel verzoek diep geneste, kostbare gegevens opvragen die geen enkele REST-route zou toestaan. Dat maakt van API4 een ontwerpbeslissing in plaats van een snelheidslimietinstelling. De andere veelvoorkomende nalatigheid is introspectie: de functie die elke client toestaat de API te vragen zijn eigen structuur te beschrijven. Publiekelijk ingeschakeld gelaten, geeft het een bezoeker een volledige kaart van uw datamodel.

gRPC en SOAP

gRPC lijkt standaard veiliger, grotendeels omdat er geen handige browsertooling is en de berichten onleesbaar zijn voor een persoon. Dat werkt tijdens het testen meer tegen u dan het in productie helpt. Service reflection, waarmee een aanroeper elke beschikbare methode kan opsommen, geeft een buitenstaander een volledige kaart van uw dienst als u het ingeschakeld laat. Rechten moeten dan per methode worden gecontroleerd in plaats van aangenomen vanuit het transport.

SOAP komt met een ingebouwde beveiligingsspecificatie, WS-Security genaamd, en dat schept een eigen valkuil. Het configureren ervan is niet hetzelfde als het toepassen op elke bewerking. XML-parsers brengen ook een hele familie problemen met zich mee die op JSON gebouwde diensten nooit tegenkomen.

Waarom Hoort API-beveiligingstesten Thuis Binnen QA?

De meest voorkomende fout die we zien, is API-beveiligingstesten behandelen als een eenmalig project in plaats van routinewerk. Het wordt eenmaal per jaar ingepland, uitgevoerd door externe specialisten, en weken na de release die het beschrijft opgeschreven.

Die regeling mist de autorisatiefouten bijna volledig, om een eenvoudige reden. Ze vinden hangt af van het begrijpen wat het product hoort te doen. Toch heeft een reviewer die voor twee weken aankomt geen manier om te weten welke velden een klant zou moeten zien, welke routes alleen voor beheerders zijn, of wie welk record bezit. Uw QA-engineers weten dit allemaal, omdat zij de functionele tests schreven die die regels coderen.

De oplossing is één kleine gewoonte bij elke release. Wie een endpoint controleert, vraagt ook een record op dat hij niet bezit, en bevestigt de weigering. Ons werk aan API-testen is zo opgebouwd, met de beveiligingscasussen die naast de alledaagse draaien in plaats van erachter.

Dat zagen we bij Union54, een kaartuitgevende API voor Afrikaanse fintechs, getest zonder enige interface. Sommige van de defecten die we meldden waren autorisatiefouten tussen verschillende soorten gebruikers. Niets daarvan kwam voort uit een specifieke beveiligingsreview. In plaats daarvan behoorden die bevindingen toe aan QA-engineers die het product goed genoeg kenden om te merken wanneer de verkeerde persoon het juiste antwoord kreeg.

Dat maakt gespecialiseerd werk niet overbodig. Een afgebakende penetratietest verdient nog steeds zijn plaats vóór een grote lancering, of wanneer een toezichthouder of een grote klant er een vraagt. Het levert echter meer op zodra de voor de hand liggende gaten zijn gedicht. De specialisten besteden hun tijd dan aan problemen die alleen zij kunnen vinden.

Hoe Bouw je een Checklist voor API-beveiligingstesten

Weten hoe u API-beveiliging test, blijkt minder te gaan over wat de lijst bevat en meer over wie eigenaar ervan is. Veel teams hebben een document, maar bijna niemand opent het tijdens een release.

Organiseer de uwe rond de OWASP-categorieën in plaats van rond uw endpoints. Een route-voor-route-inventaris veroudert de week nadat u het schreef, terwijl die risicogroeperingen stabiel blijven over releases en technologieën heen. Noteer onder elke wat er wordt gecontroleerd, op welke paden het van toepassing is, en wie het afvinkt.

Vier beslissingen doen meer voor een checklist dan de inhoud ervan:

• Geef het één eigenaar met de bevoegdheid om een lancering te blokkeren, nooit een gedeelde inbox.
• Koppel het aan het releaseproces dat uw team al volgt in plaats van aan een aparte beveiligingsagenda.
• Schrijf elk item als een verzoek plus een verwachte weigering, zodat iedereen het kan uitvoeren en het resultaat kan lezen.
• Herzie het telkens wanneer u een route toevoegt, een rechtenmodel wijzigt, of een nieuwe externe integratie aangaat.

Twee aangrenzende stukken zijn het waard om ernaast open te houden:

• Onze REST API-testchecklist dekt de betrouwbaarheidshelft, en de overlap is nuttig, aangezien een beveiligingscasus vaak een functionele is met het verwachte resultaat omgekeerd.
• Ons werk aan API-performancetesten hoort hier ook thuis, omdat wat misbruik ook beperkt, u ook door een verkeerspiek heen draagt.

Een waarschuwing over tooling. Scanners doen het goed op verkeerde configuratie en tokenafhandeling, waar fouten herkenbare patronen volgen. Ze zijn bijna nutteloos op de drie autorisatierisico’s, want geen enkele tool kan weten wie een bepaalde factuur zou moeten bezitten. Alleen uw team heeft die kennis, dus het werk hoort binnen kwaliteitsborging in plaats van erbuiten.

Wij auditen API’s tegen de OWASP-lijst in welke fase uw product zich ook bevindt, of de build klaar is of de endpoints nog worden geschreven. Om te ontdekken wat uw API overhandigt aan een aanroeper die om meer vraagt dan hij zou moeten, praat met ons QA-team.

Wat is API-beveiligingstesten?

API-beveiligingstesten controleert of een API misbruikt kan worden door iemand die al geldige inloggegevens heeft. Het behandelt authenticatie, autorisatie bij elk verzoek, snelheids- en payloadlimieten, en wat reacties prijsgeven. Het referentiekader is de OWASP API Security Top 10, die verschilt van de algemene webapplicatielijst omdat API-risico zich concentreert op autorisatie in plaats van injectie.

Heeft GraphQL andere beveiligingstesten nodig dan REST?

Ja, hoewel de OWASP-lijst voor beide geldt. REST legt record-identifiers open in het adres, dus de eerste controle is of het verwisselen van één ervan de gegevens van een andere klant oplevert. GraphQL laat de client zijn eigen query samenstellen, wat de risico’s verschuift naar querydiepte, kostenlimieten, en of introspectie publiek is.

Hoe verschilt de OWASP API-lijst van de webapplicatie Top 10?

De webapplicatielijst behandelt toegangscontrole als één brede categorie. De API-lijst splitst dit op in drie: objectniveau, objecteigenschapniveau, en functieniveau. Dat weerspiegelt hoe API-fouten daadwerkelijk gebeuren, waarbij een correct geauthenticeerde aanroeper records ontvangt die aan iemand anders toebehoren. Injectie- en scriptingrisico’s, die webtesten domineren, tellen bij de meeste API’s minder.

Kan functionele QA API-beveiligingsproblemen vinden?

Ja, en voor autorisatiefouten is het meestal de meest effectieve plek om te kijken. Ze vinden betekent weten wie elk record zou moeten zien, en uw QA-engineers coderen die regels al in functionele tests. Het negatieve geval naast het positieve schrijven vangt de meeste van die autorisatiefouten ruim voordat een gespecialiseerde review plaatsvindt.

Hoe vaak moet API-beveiligingstesten worden uitgevoerd?

Voer de autorisatie- en invoercontroles bij elke release uit, binnen uw normale testcyclus, want een enkele rechtenwijziging kan een gat openen. Bewaar gerichte penetratietesten voor grote lanceringen, architectuurwijzigingen, of een compliance-vereiste. Jaarlijks testen alleen laat u elf maanden lang blootgesteld terwijl het product blijft veranderen.