Cloud, QA en beveiliging

API-beveiligingstests voor REST en GraphQL

Gjethe test API's rechtstreeks, zoals aanvallers dat doen: autorisatie op elk object, authenticatie, hoeveel data antwoorden teruggeven, mass assignment, rate limits en bedrijfsflows. Het testen volgt de OWASP API Security Top 10 en elke bevinding komt met bewijs, een oplossing en een hertest.

  • Gratis eerste adviesgesprek
  • Schriftelijke offerte voor uw project
  • Flexibele betaalmijlpalen
✓ build passed

In één oogopslag

API-typen
REST, GraphQL, WebSocket
Standard
OWASP API Security Top 10
Focus
Autorisatie, blootstelling van data, rate limits
Resultaat
Rapport, oplossingen en hertest

Definition

Wat is API-beveiligingstesten?

API-beveiligingstesten is het beoordelen van een application programming interface op zwakke plekken waardoor aanroepers bij data of functies kunnen die ze niet mogen bereiken, door speciaal gemaakte verzoeken rechtstreeks naar de endpoints te sturen.

Mobiele apps, single-page webapps, partners en integraties praten allemaal met uw API. De interface kan velden en knoppen verbergen, maar de API antwoordt iedereen die het juiste verzoek stuurt. Daarom leggen API's vaak meer bloot dan bedoeld: volledige records terwijl de app alleen een naam toont, acties die bereikbaar zijn door een adres te wijzigen, of geen limiet op hoe snel iemand logins kan proberen of data kan ophalen. API-testen zet de interface opzij en controleert wat de server zelf toestaat.

Voor wie is het?

  • Teams met een openbare of partner-API

    Alles wat voor andere ontwikkelaars openstaat, staat open voor iedereen die uw documentatie leest.

  • Backends van mobiele apps

    De app is slechts één client; de API moet zichzelf tegen elk verzoek verdedigen.

  • Microservice-architecturen

    Interne services vertrouwen elkaar vaak te veel; wij controleren die grenzen.

  • Producten met betalingen of tegoeden

    Geld, saldi en quota zijn favoriete doelwitten voor misbruik van logica en rate limits.

Wat is inbegrepen en wat u houdt

Wat is inbegrepen

  • Review van API-documentatie en schema
  • Ontdekken van endpoints en operaties
  • Testen van autorisatie op objectniveau
  • Testen van autorisatie op functieniveau
  • Review van authenticatie en tokenbeheer
  • Controles op overmatige blootstelling van data
  • Tests op mass assignment en verwerking van invoer
  • Testen van rate limiting en misbruik van resources
  • Testen van bedrijfsflows en volgordes
  • GraphQL-specifieke controles waar relevant
  • Review van transport en configuratie
  • Rapport met bewijs, oplossingen en een hertest

Wat u ontvangt

Aan het einde overgedragen. Van u om te houden.

  • API-beveiligingstestrapport
  • Bevindingen gekoppeld aan de OWASP API Top 10
  • Heldere beschrijving van elk bevestigd probleem
  • Aanbevelingen voor oplossing per bevinding
  • Hertestrapport

OWASP API Security Top 10-gebieden die wij afdekken

GebiedVoorbeeld van wat wij controleren
Kapotte autorisatie op objectniveauHet record van een andere gebruiker lezen door een identificator te wijzigen
Kapotte authenticatieZwakke tokens, ontbrekende vervaltijd, raadbare inloggegevens
Kapotte autorisatie op objecteigenschappenVelden instellen die de aanroeper niet mag bepalen
Onbeperkt verbruik van resourcesGeen rate limits op kostbare of gevoelige operaties
Kapotte autorisatie op functieniveauBeheeroperaties aanroepen als gewone gebruiker
Onbeperkte toegang tot bedrijfsflowsEen flow automatiseren die maar één keer bedoeld is
Server-side request forgeryDe API haalt adressen op die een aanroeper bepaalt
Verkeerde beveiligingsconfiguratieUitgebreide foutmeldingen, debug-endpoints, losse instellingen
Onjuist inventarisbeheerVergeten oude versies die nog verzoeken accepteren
Onveilig gebruik van derdenData van een externe API vertrouwen zonder controles

Waarom API's meer lekken dan de app toont

Een webpagina toont een klant alleen de eigen naam. Het verzoek erachter kan echter het hele gebruikersrecord teruggeven, inclusief velden die de pagina stilzwijgend negeert. Aanvallers lezen antwoorden rechtstreeks, dus alles wat de server verstuurt is in feite openbaar voor wie het endpoint kan aanroepen.

Wij testen vanaf de kant van de aanroeper: elk endpoint wordt gebruikt als verschillende gebruikers en rollen, met gewijzigde identificatoren en velden, om te zien of de server controleert wie er vraagt en alleen teruggeeft wat diegene mag zien. GraphQL krijgt extra aandacht, omdat één flexibele query veel meer kan bereiken dan een vaste REST-route als de regels niet per veld worden afgedwongen.

Waarom API's eigen tests nodig hebben

Het is verleidelijk te denken dat het testen van de website ook de API erachter test. Dat is niet zo. De website gebruikt de API op de manier die de ontwerpers bedoelden, via de knoppen en schermen die zij bouwden. Een aanvaller negeert dat alles en roept de endpoints rechtstreeks aan, in elke volgorde, met elke waarde, als elk account dat hij kan bemachtigen. Hele categorieën problemen verschijnen alleen vanuit die hoek: een endpoint dat een gebruikers-ID uit het verzoek vertrouwt, een veld dat alleen-lezen zou moeten zijn maar beschrijfbaar is, een operatie zonder limiet op hoe vaak die draait.

De API apart testen beschermt ook elke client die ervan afhangt. Eén API bedient meestal een webapp, een mobiele app en vaak ook partnerintegraties tegelijk. Een zwakke plek daar staat voor al die clients open, dus oplossen op API-niveau beschermt het hele product en niet slechts één scherm.

Hoe API-beveiligingstesten werken, stap voor stap

Elke stap heeft een duidelijk resultaat dat u kunt beoordelen. De planning wordt afgesproken in uw offerte.

  1. 1

    Scope

    API's, omgevingen, rollen en testinloggegevens schriftelijk afgesproken.

  2. 2

    Kaart

    Endpoints, operaties en rollen geïnventariseerd uit documentatie en verkeer.

  3. 3

    Testen

    Autorisatie, authenticatie, blootstelling van data en misbruik handmatig getest.

  4. 4

    Verifiëren

    Elke bevinding zorgvuldig bevestigd, met veilig bewijs.

  5. 5

    Rapport

    Bevindingen gekoppeld aan de API Top 10, met oplossingen.

  6. 6

    Hertest

    Oplossingen geverifieerd en het rapport bijgewerkt.

Tools, en wat uw offerte bepaalt

De prijs hangt af van uw project en wordt afgesproken in uw offerte. Dit zijn de zaken die hem beïnvloeden.

API-beveiligingstesten: prijsfactoren
FactorWaarom het ertoe doet
Aantal endpointsMeer operaties betekenen meer autorisatie- en invoertests.
Aantal rollenElke rol moet worden getest tegen elke gevoelige operatie.
REST versus GraphQLGraphQL vraagt om controles per veld en tests van querykosten.
Kwaliteit van de documentatieGoede schema's en collecties maken testen sneller en completer.
BedrijfsflowsBetalingen, quota en flows met meerdere stappen vragen om zorgvuldig logica testen.

Veelgemaakte fouten die u moet vermijden

Wat we het vaakst mis zien gaan, en hoe een goed project dat voorkomt.

  • Rechten alleen in de app controleren

    Als de API niet bij elk verzoek opnieuw controleert, betekenen de beperkingen van de app niets.

  • Hele objecten teruggeven

    Volledige records versturen en de client velden laten kiezen legt alles bloot voor iedereen die antwoorden leest.

  • Geen rate limits

    Zonder limieten kunnen logins worden geraden en kan data in bulk worden opgehaald.

  • Vergeten oude versies

    Oude API-versies die blijven draaien missen vaak de oplossingen die aan de huidige zijn toegevoegd.

Veelgestelde vragen

Hebt u onze API-documentatie nodig?

Het helpt enorm. Een schema, Postman-collectie of OpenAPI- of GraphQL-definitie versnelt het testen en verbetert de dekking. Waar die ontbreekt, brengen we endpoints in kaart uit het verkeer van uw clients.

Kunt u een GraphQL-API testen?

Ja. GraphQL vraagt om autorisatiecontroles per veld en tests van querykosten, die wij naast de standaard API-gebieden afdekken.

Heeft het testen invloed op onze productiedata?

Wij geven de voorkeur aan een stagingomgeving met testdata. Als we productie moeten testen, gebruiken we testaccounts, spreken we periodes af en vermijden we acties die echte records wijzigen.

Test u authenticatieproviders zoals OAuth?

Wij testen hoe uw API tokens en sessies gebruikt: vervaltijd, scope, validatie en afhandeling. De identity provider zelf valt meestal buiten de scope, tenzij u die zelf beheert.

Hoe verschilt dit van een test van een webapp?

Een webapptest werkt via de interface; een API-test werkt rechtstreeks op endpoints, en daar sluiten mobiele apps, integraties en single-page apps daadwerkelijk aan.

Is een hertest inbegrepen?

Ja. Nadat u de bevindingen hebt opgelost, testen wij ze opnieuw en werken we het rapport bij.

Kunt u helpen de bevindingen op te lossen?

Ja. Onze ontwikkelaars kunnen de oplossingen doorvoeren of de wijzigingen van uw team beoordelen vóór de hertest.

Tekent u een NDA?

Ja. Bevindingen zijn vertrouwelijk en worden alleen gedeeld met de contactpersonen die u noemt, en testdata wordt daarna verwijderd.

Test u ook oudere API-versies?

Ja, wanneer ze binnen de scope vallen. Oude versies die blijven draaien zijn een veelvoorkomende zwakke plek, omdat de oplossingen die aan de huidige versie zijn toegevoegd er vaak nooit op worden toegepast.

Wat hebt u van ons nodig om te starten?

Het basisadres van elke API, inloggegevens voor elke rol, eventuele schema's of documentatie die u hebt en een aangewezen contactpersoon voor als er tijdens het testen iets aandacht nodig heeft.

Zie wat uw API echt toestaat.

Vertel ons wat u nodig hebt. U krijgt een eerlijke beoordeling, een duidelijk plan en een schriftelijke offerte. Het eerste adviesgesprek is altijd gratis.

  1. Wat er daarna gebeurt
  2. 1U vertelt ons wat u nodig hebt
  3. 2We streven ernaar binnen 24 uur te reageren met vragen
  4. 3U ontvangt een schriftelijke offerte voor uw project