API's: het nieuwe aanvalsoppervlak

API's (Application Programming Interfaces) zijn de meest doelwitlaag in moderne software geworden: 150 miljard van de in totaal 311 miljard webaanvallen in 2024 waren gericht op API's, volgens het State of the Internet-rapport van Akamai uit 2024. API's bieden directe programmatische toegang tot applicatielogica en gevoelige gegevens, en ze verspreiden zich sneller dan de beveiligingsmaatregelen eromheen. De aanbevolen aanpak: behandel elke API als een bevoorrecht toegangspunt, dwing TLS 1.3 en wederzijdse TLS af voor al het verkeer, implementeer autorisatie op objectniveau bij elk eindpunt en monitor het API-gedrag continu op afwijkingen die alleen met signatures niet kunnen worden gedetecteerd.

Kort antwoord: Waarom vormen API's het nieuwe aanvalsoppervlak?

API's hebben de traditionele applicatielagen verdrongen als het belangrijkste aanvalsoppervlak, om drie elkaar versterkende redenen. Ten eerste bieden ze directe, programmatische toegang tot gevoelige gegevens en bedrijfslogica zonder de wrijving van een gebruikersinterface. Ten tweede vermenigvuldigen ze zich snel naarmate organisaties microservices bouwen en platforms van derden integreren, waardoor honderden eindpunten per applicatie ontstaan ​​met inconsistente beveiligingsmaatregelen. Ten derde zijn API-specifieke kwetsbaarheden zoals Broken Object Level Authorization (BOLA, OWASP API1:2023) structureel anders dan traditionele webkwetsbaarheden en worden ze niet gedetecteerd door standaard WAF-regels of kwetsbaarheidsscanners die zijn ontworpen voor HTML-pagina's. Uit het rapport van FireTail uit 2024 bleek dat 57% van de organisaties in de afgelopen twee jaar minstens één API-inbreuk heeft meegemaakt, en dat 73% van de getroffen organisaties drie of meer incidenten heeft ondervonden.

Wat is API-beveiliging?

Een API is een set regels en protocollen waarmee softwareapplicaties met elkaar kunnen communiceren. Het definieert hoe verzoeken worden gedaan, hoe gegevens worden uitgewisseld en hoe reacties worden gestructureerd, waardoor systemen op een gestandaardiseerde manier kunnen samenwerken. API's vormen de basis van vrijwel elke moderne technologie-stack: bankapps, zorgportalen, e-commerceplatforms, cloudinfrastructuur en interne microservices communiceren allemaal via API-aanroepen.

REST (Representational State Transfer) API's blijven de dominante standaard. GraphQL (Graph Query Language) API's stellen clients in staat om precies aan te geven welke gegevens ze nodig hebben en hebben nieuwe aanvalsoppervlakken geïntroduceerd, waaronder misbruik van introspectie en uitputting van diep geneste query's. gRPC (Google Remote Procedure Call) gebruikt protocolbuffers en HTTP/2 voor snelle servicecommunicatie. WebSocket API's maken persistente bidirectionele communicatie mogelijk voor realtime-applicaties. Elk API-type heeft een eigen beveiligingsprofiel dat specifieke controles vereist die verder gaan dan de algemene webapplicatiebeveiliging.

API-beveiliging verwijst naar de reeks beheersmaatregelen die API's beschermen tegen ongeautoriseerde toegang, datalekken, misbruik en denial-of-service-aanvallen. Omdat API's fungeren als directe toegangspunten tot de backends van applicaties, is zwakke API-beveiliging vaak de gemakkelijkste weg voor aanvallers die de traditionele perimeterbeveiliging al hebben uitgeput.

API-dreigingsmodel: aanvalsvectoren en wat ze exploiteren

OWASP API-beveiliging Top 10 (2023)	Wat het exploiteert	Voorbeeld	Primaire controle
API1: Gebroken autorisatie op objectniveau (BOLA)	Er ontbreken autorisatiecontroles per object; de API verifieert de authenticatie, maar niet of de gebruiker de specifieke resource bezit.	Als je /api/orders/1234 wijzigt naar /api/orders/1235, krijg je de bestelling van een andere gebruiker terug.	Dwing autorisatie op objectniveau af bij elk eindpunt, niet alleen op sessieniveau.
API2: Defecte authenticatie	Zwakke tokenvalidatie, ontbrekende vervaldatum, tokens van verkeerde uitgevers worden geaccepteerd.	JWT met algoritme: geen geaccepteerd; verlopen tokens worden niet afgewezen	Valideer JWT-handtekeningen en -claims; handhaaf de vervaldatum van tokens; gebruik kortstondige tokens.
API3: Defecte autorisatie op objecteigenschapsniveau	De API retourneert of accepteert meer velden dan de gebruiker mag zien of instellen.	Massale toewijzingsaanval met instelling admin:true in een gebruikersupdateverzoek	Expliciete lijst met toegestane velden per eindpunt per rol
API4: Onbeperkt resourceverbruik	Geen snelheidsbeperking; de API verwerkt onbeperkt verzoeken, ongeacht het verbruik van CPU, geheugen of downstreamkosten.	Massale opsomming van gebruikersgegevens; uitputting van query's via diep geneste GraphQL-query's	Snelheidsbeperking per API-sleutel, IP-adres en gebruiker; limieten voor querydiepte en complexiteit voor GraphQL.
API5: Defecte autorisatie op functieniveau	Administratieve API-functies die beschikbaar zijn voor niet-beheerders.	Niet-beheerders hebben toegang tot /api/admin/users om alle gebruikers weer te geven.	Aparte beheerders-API's; rolgebaseerde toegangscontrole afdwingen op functieniveau.
API6: Onbeperkte toegang tot gevoelige bedrijfsprocessen	API's die risicovolle bedrijfslogica (accountaanmaak, betaling) mogelijk maken zonder flowcontrols.	Het automatiseren van accountaanmaak om een ​​leger van bots te bouwen dat de voorraad beheert voor kassasystemen in de detailhandel.	Snelheidsbeperking voor bedrijfslogica; CAPTCHA voor gevoelige gegevensstromen; detectie van afwijkingen in gegevensstroompatronen.
API7: Server-Side Request Forgery (SSRF)	De API haalt door de gebruiker opgegeven URL's op, waardoor toegang tot interne services mogelijk wordt.	API die een URL ophaalt die verwijst naar de interne metadataservice, waarmee cloudreferenties worden weergegeven.	Voeg toegestane URL-bestemmingen toe aan de whitelist; blokkeer privé-IP-adressen op applicatieniveau.
API8: Beveiligingsfout in de configuratie	Standaardreferenties, uitgebreide foutmeldingen, open debug-eindpunten, ontbrekende TLS	Elasticsearch-database toegankelijk zonder authenticatie; API retourneert stacktraces in foutmeldingen	Debugmodi uitschakelen in productieomgevingen; generieke foutmeldingen gebruiken; configuraties controleren.
API9: Onjuist voorraadbeheer	Niet-gedocumenteerde of verouderde API-eindpunten zijn nog steeds actief en worden niet gemonitord.	Het oude v1 API-eindpunt met zwakkere authenticatie is actief naast het beveiligde v2-eindpunt.	Zorg voor een complete inventarisatie van API's; verwijder verouderde versies; monitor alle actieve eindpunten.
API10: Onveilig gebruik van API's	De eigen systemen van de organisatie vertrouwen blindelings op gegevens van API's van derden zonder validatie.	De API van de betalingsprovider retourneert een kwaadaardige redirect-URL die zonder validatie wordt uitgevoerd.	Beschouw alle reacties van externe API's als onbetrouwbare invoer; valideer en zuiver ze vóór gebruik.

API-inbreuken in de praktijk: wat is er werkelijk gebeurd?

• GitHub-repositories (maart 2024): Ongeveer 13 miljoen API-geheimen zijn via openbare repositories openbaar gemaakt als gevolg van gebrekkig beheer van geheimen. Aanvallers gebruikten deze inloggegevens om ongeautoriseerde toegang te verkrijgen tot cloudservices en downstream-applicaties. Preventie: gebruik tools voor het scannen op geheimen, zoals GitHub Advanced Security of TruffleHog, in CI/CD-pipelines; commit nooit API-sleutels, tokens of inloggegevens naar code repositories.
• Dell API-inbreuk (2024): Een blootgestelde API in het partnerportaal van Dell gaf aanvallers toegang tot gegevens van 49 miljoen klanten. De inbreuk werd in verband gebracht met ontoereikende beperking van het aantal aanvragen en het ontbreken van anomaliedetectie in het API-verkeer. Dit is een direct voorbeeld van OWASP API4 (onbeperkt resourcegebruik) in combinatie met API8 (beveiligingsfout).
• Misbruik van de Microsoft Graph API (mei 2024): Aanvallers hebben de Microsoft Graph API misbruikt om verborgen communicatiekanalen voor malware te creëren die duizenden organisaties troffen. Door legitiem verkregen API-toegang te gebruiken, omzeilden ze traditionele perimeterbeveiligingsmaatregelen. Dit is een Living off the Land (LotL)-aanval: kwaadaardige activiteit waarbij legitieme tools worden gebruikt die opgaan in de normale bedrijfsvoering en die gedragsdetectie vereist in plaats van op signaturen gebaseerde controles.
• APIsec-incident (maart 2025): Een verkeerd geconfigureerde Elasticsearch-database van API-testbedrijf APIsec heeft meer dan drie terabyte aan gevoelige klantgegevens blootgelegd, waaronder API-scanresultaten, configuratiegeheimen en persoonsgegevens. Een OWASP API8-fout (beveiligingsfout) op databaseniveau legde gegevens bloot die waren verzameld door een API-beveiligingstool.
• Thee-app (2025): Een anonieme sociale app is gehackt, waardoor 1.1 miljoen privéberichten en duizenden identiteitsdocumenten van gebruikers openbaar zijn geworden als gevolg van slecht beveiligde opslag en API-eindpunten. Gevoelige informatie, waaronder telefoonnummers en identiteitsdocumenten, was toegankelijk via onbeveiligde API-eindpunten, een gecombineerde fout in API8 en API1.

Versleuteling en protocolselectie voor API-beveiliging

Versleuteling beschermt API-gegevens tijdens overdracht en opslag. De protocolkeuze bepaalt of de versleuteling sterk genoeg is voor de te beschermen gegevens:

Controleer:	Aanbeveling	Wat te vermijden	Relevantie voor naleving
Versleuteling van extern API-verkeer	TLS 1.3; TLS_AES_256_GCM_SHA384 of TLS_CHACHA20_POLY1305_SHA256	TLS 1.0, TLS 1.1, SSL; CBC-modus cipher suites; RSA-sleuteluitwisseling (geen PFS)	AVG-artikel 32; HIPAA-beveiligingsregel; PCI DSS-vereiste 4
Interne API-authenticatie tussen services	Mutual TLS (mTLS) met certificaatgebaseerde identiteit per service	Gedeelde statische API-sleutels zonder rotatie; geen authenticatie tussen interne services.	PCI DSS-vereiste 8; vereisten voor zero-trust-architectuur
API-geheimen en -gegevens in rust	AES-256-GCM in een speciaal systeem voor geheimbeheer of HSM; nooit in code repositories.	Platte tekst in omgevingsvariabelen, configuratiebestanden of versiebeheer.	HIPAA; PCI DSS Vereiste 3; AVG Artikel 32
Tokenoverdracht	Autorisatieheader (Bearer-token); nooit in URL-queryreeksen.	Tokens in URL-queryparameters (geregistreerd door proxies, CDN's en servertoegangslogboeken)	PCI DSS-vereiste 6; OWASP API-beveiliging Top 10
Langdurige API-gegevens (PQC-overweging)	Hybride TLS: ECDHE + ML-KEM (FIPS 203) voor API's die gegevens transporteren die 10 jaar of langer gevoelig zijn.	Alleen RSA-sleuteluitwisseling voor API's die gevoelige gegevens met een lange bewaartermijn verzenden.	NIST IR 8547 2030 uitfaseringstijdlijn

Authenticatie, autorisatie en toegangscontrole

Authenticatie- en autorisatiefouten zijn verantwoordelijk voor het merendeel van de exploiteerbare API-kwetsbaarheden in de OWASP Top 10 van 2023. Deze controles moeten op elk niveau correct worden geïmplementeerd:

• OAuth 2.0 en OpenID Connect: OAuth 2.0 is de standaard voor gedelegeerde autorisatie; OpenID Connect (OIDC) voegt daar identiteitsverificatie aan toe. Gebruik de autorisatiecodeflow met PKCE (Proof Key for Code Exchange) voor alle API-authenticatie die door gebruikers wordt gebruikt. Machine-to-machine API's moeten de clientreferentieflow met kortstondige toegangstokens gebruiken.
• JWT (JSON Web Token) validatie: Valideer de handtekening, de uitgever (iss claim), het publiek (aud claim) en de vervaldatum (exp claim) bij elk verzoek. Accepteer nooit JWT's met algorithm:none. Gebruik asymmetrische sleutelverificatie (RS256 of ES256) in plaats van gedeelde symmetrische geheimen (HS256) voor implementaties met meerdere services.
• Multi-factor authenticatie (MFA): Toegang tot API's die door mensen wordt geïnitieerd (ontwikkelaarsportalen, API-beheerconsoles) moet het volgende vereisen: MFA. FIDO2-wachtwoorden of op certificaten gebaseerde authenticatie Via CertSecure Manager worden phishingbestendige alternatieven voor TOTP aangeboden.
• Mutual TLS (mTLS): mTLS Het vereist dat zowel de client als de server geldige certificaten presenteren tijdens de TLS-handshake. Voor interne service-to-service API's in microservice- of zero-trust-architecturen zorgt mTLS ervoor dat alleen geautoriseerde services verbindingen kunnen leggen, waardoor de authenticatie op basis van alleen referenties, waarop BOLA- en gebroken authenticatie-aanvallen zijn gebaseerd, wordt geëlimineerd.
• OCSP-nieten: in staat stellen OCSP-nieten Op API-servers worden realtime controles op de geldigheid van certificaten uitgevoerd zonder dat clients de certificeringsinstantie afzonderlijk hoeven te raadplegen. Dit vermindert de latentie en voorkomt misbruik van ingetrokken certificaten.
• Minste privileges en RBAC: Elke API-client, gebruiker en serviceaccount ontvangt alleen de minimale machtigingen die nodig zijn voor de betreffende functie. Op rollen gebaseerd toegangsbeheer (RBAC) of op attributen gebaseerd toegangsbeheer (ABAC), afgedwongen op API-gateway- en objectniveau, lost problemen met BOLA en autorisatiefouten op functieniveau op.

Monitoring, registratie en incidentafhandeling

API-aanvallen slagen vaak niet omdat er geen verdediging is, maar omdat afwijkend gedrag pas wordt opgemerkt nadat er al aanzienlijke schade is aangericht. De datalek bij Dell was bijvoorbeeld te wijten aan een gebrek aan detectie van afwijkingen in het API-verkeer. Effectieve monitoring vereist:

• Gedragsbasislijn en anomaliedetectie: Stel vast hoe normaal API-verkeer er per endpoint uitziet: verwachte aanvraagvolumes, typische client-ID's, standaard geografische spreiding en normale responsgroottes. Afwijkingen, zoals een enkele API-sleutel die 50,000 aanvragen per uur doet, of responsen die consequent groter zijn dan de basislijn, zijn detectiesignalen. Op signaturen gebaseerde regels detecteren bekende patronen; gedragsdetectie detecteert nieuwe aanvallen en misbruik van LotL.
• SIEM-integratie: integreren SIEM Platformen met API-gatewaylogs, authenticatielogs en applicatielogs. SIEM-correlatie identificeert aanvalspatronen die normaal lijken in individuele logstromen, maar afwijkend zijn wanneer ze over verschillende bronnen worden gecorreleerd.
• Volledige auditregistratie: Registreer elke API-aanvraag met de clientidentiteit, het eindpunt, de HTTP-methode, de aanvraagparameters, de responsstatuscode, de responsgrootte en het tijdstempel. Logboeken moeten worden opgeslagen in een schrijfbeveiligde omgeving, gescheiden van de applicatie, zodat een gecompromitteerde server het auditspoor niet kan wijzigen. De bewaartermijn van de logboeken moet voldoen aan de toepasselijke wettelijke vereisten (12 maanden volgens PCI DSS-vereiste 10).
• API-inventarisbewaking: Niet-gedocumenteerde en verouderde eindpunten worden steevast misbruikt omdat ze niet worden gemonitord. Zorg voor een volledig overzicht van de API's en bevestig dat de monitoring 100% van de actieve eindpunten dekt, inclusief verouderde versies die buiten gebruik gesteld zouden moeten worden.

Best practices voor het beveiligen van API's: implementatiechecklist

1. Dwing TLS 1.3 af op alle API-eindpunten; Schakel TLS 1.0, 1.1 en cipher suites zonder perfect forward secrecy uit.
2. Implementeer autorisatie op objectniveau op elk eindpunt; Ga er niet van uit dat authenticatie op sessieniveau voldoende is om BOLA te voorkomen.
3. Valideer en zuiver alle invoergegevens; Handhaaf JSON-schemavalidatie voor REST API's, stel limieten in voor querydiepte en -complexiteit voor GraphQL en weiger onjuist geformuleerde verzoeken voordat ze de applicatielogica bereiken.
4. Implementeer snelheidsbeperking per API-sleutel, gebruiker en IP-adres; Pas exponentiële backoff toe bij herhaalde mislukte authenticatiepogingen.
5. Bewaar alle geheimen in een speciaal systeem voor geheimenbeheer, een HSM (Hardware Security Module). API-sleutels volgens een vast schema roteren; repositories scannen op per ongeluk opgeslagen inloggegevens.
6. Gebruik mTLS voor interne communicatie tussen services; Beheer servicecertificaten via een geautomatiseerd platform voor levenscyclusbeheer.
7. Zorg voor een complete en actuele inventaris van API's; Verwijder verouderde eindpunten; monitor alle actieve eindpunten, inclusief de niet-gedocumenteerde.
8. Integreer DAST-tools (Dynamic Application Security Testing) zoals OWASP ZAP in CI/CD-pipelines; Voer vóór elke implementatie API-specifieke beveiligingstests uit.
9. Registreer elk API-verzoek met volledige verzoekmetadata; Integreer met SIEM; configureer waarschuwingen voor anomaliedetectie bij volumepieken, ongebruikelijke toegangspatronen en reacties die significant afwijken van de basisgrootte.
10. Voer een dreigingsanalyse uit met STRIDE voor elke nieuwe API; Koppel elke dreigingscategorie aan een specifieke beheersmaatregel vóór de implementatie, in plaats van na een inbreuk.

Hoe encryptieconsultancy kan helpen

• Adviesdiensten op het gebied van encryptie: Encryptie Adviesdiensten We beoordelen de dekking van API-versleuteling, inclusief TLS-configuratie, selectie van cipher suites, beheer van geheimen en mTLS-implementatie. We identificeren hiaten tussen de huidige API-beveiliging en de vereisten van NIST, GDPR, HIPAA en PCI DSS, en bieden een prioriteitsplan voor herstel.
• Auditdienst voor versleuteling: Encryptie-auditservice Dit biedt een grondig onderzoek naar cryptografische praktijken binnen uw API-infrastructuur, waarbij blootgestelde geheimen, zwakke algoritmen, ontbrekende TLS-handhaving en PQC-gereedheidstekorten worden geïdentificeerd. We beoordelen ook de HNDL-blootstelling voor API's die langdurig gevoelige gegevens transporteren.
• CertSecure Manager: CertSecure Manager Automatiseert het beheer van de certificaatlevenscyclus voor de mTLS-certificaten die worden gebruikt voor interne API-authenticatie, inclusief ontdekking, uitgifte, verlenging en intrekking binnen uw service mesh.
• HSM als een service: HSM als een service Biedt FIPS 140-3 gevalideerde hardwareopslag voor de API-ondertekeningssleutels en encryptiesleutels die, indien gecompromitteerd, al het API-verkeer zouden blootleggen. HSM-opslag voorkomt het extraheren van sleutels, zelfs in geval van een servercompromis.
• PQC-adviesdiensten: PQC Adviesdiensten Beoordeel welke API's een HNDL-risico lopen door de kwantumdreiging, plan hybride TLS-implementaties die ECDHE combineren met ML-KEM (FIPS 203), en lever een migratieplan in negen fasen dat is afgestemd op de uitfaseringstermijn van 2030 zoals beschreven in NIST IR 8547.

Beperkingen: Wat API-beveiligingsmaatregelen niet alleen kunnen doen

• Versleuteling voorkomt geen mislukte autorisatiepogingen: TLS beveiligt het kanaal; het voorkomt geen BOLA (Body On-Label Attacks). Een aanvaller die een geldig token gebruikt om via een correct versleutelde verbinding toegang te krijgen tot de gegevens van een andere gebruiker, slaagt daar nog steeds in. Versleuteling en autorisatie zijn aparte beveiligingslagen die verschillende bedreigingen aanpakken.
• WAF's detecteren geen API-specifieke kwetsbaarheden: Traditionele webapplicatiefirewalls zijn ontworpen voor aanvallen op HTML-pagina's (XSS, SQL-injectie in formuliervelden) en dekken niet de OWASP API Security Top 10-kwetsbaarheden zoals BOLA of autorisatiefouten op functieniveau, die detectie vereisen op applicatieniveau.
• Statische tests vervangen runtime-monitoring niet: DAST en penetratietesten sporen kwetsbaarheden op vóór de implementatie; gedragsanalyse detecteert aanvallen in productie. Geen van beide vervangt de ander. LotL-aanvallen, waarbij legitieme toegang wordt misbruikt, kunnen alleen worden gedetecteerd door middel van gedragsanalyse tijdens de uitvoering.
• API-gateways zijn geen complete beveiligingsoplossingen: Gateways bieden gecentraliseerde authenticatie, snelheidsbeperking en logging, maar ze dwingen geen autorisatie op objectniveau af (wat in de applicatielogica moet worden geïmplementeerd) en detecteren geen misbruik van LotL (wat gedragsmonitoring vereist).

Conclusie

API's vormen de ruggengraat van moderne digitale ecosystemen, en juist die centrale rol maakt ze tot het meest productieve doelwit voor aanvallers. Met 150 miljard API-aanvallen in 2024 en 57% van de organisaties die de afgelopen twee jaar te maken hebben gehad met API-inbreuken, is de vraag niet of de API's van een organisatie doelwit zullen worden, maar of de beveiligingsmaatregelen de schade kunnen beperken als dat wel gebeurt.

Effectieve API-beveiliging vereist gelaagde controles die verschillende bedreigingscategorieën aanpakken: TLS 1.3 met mTLS voor kanaalbeveiliging, OAuth 2.0 met autorisatie op objectniveau voor toegangscontrole, snelheidsbeperking en anomaliedetectie ter voorkoming van misbruik, door HSM ondersteund geheimbeheer voor de bescherming van inloggegevens en continue gedragsmonitoring voor aanvallen die door signatures worden gemist. Elke laag pakt een specifieke bedreigingsklasse aan; het verwijderen van één laag laat een gat achter dat de andere lagen niet kunnen dichten.

Wilt u uw huidige API-versleuteling beoordelen, lacunes in authenticatie en autorisatie identificeren of cryptografische beveiligingsmaatregelen implementeren die API-gegevens beschermen wanneer alle andere opties falen? Neem dan contact op met Encryption Consulting voor een API-beveiligingsanalyse.

Veelgestelde Vragen / FAQ

Waarom vormen API's tegenwoordig het belangrijkste aanvalsoppervlak?

API's bieden directe programmatische toegang tot applicatielogica en gevoelige gegevens, verspreiden zich sneller dan beveiligingsmaatregelen en bevatten kwetsbaarheden (BOLA, gebroken autorisatie op functieniveau) die standaard webbeveiligingstools niet detecteren. 150 miljard van de 311 miljard webaanvallen in 2024 waren gericht op API's (Akamai 2024 SOTI). FireTail constateerde dat API-inbreuken in 2024 met 80% zijn gestegen ten opzichte van het jaar ervoor.

Wat is BOLA (Broken Object Level Authorization)?

BOLA (OWASP API1:2023) treedt op wanneer een API een gebruiker authenticeert, maar niet controleert of deze gebruiker gemachtigd is om toegang te krijgen tot een specifiek object. Een aanvaller wijzigt een object-ID in de URL van het verzoek om toegang te krijgen tot de gegevens van een andere gebruiker. Preventie vereist autorisatiecontroles op objectniveau voor elk eindpunt, niet alleen authenticatie op sessieniveau.

Welke versleuteling is vereist voor API-beveiliging?

TLS 1.3 voor al het externe API-verkeer; wederzijdse TLS (mTLS) voor interne communicatie tussen services; AES-256-GCM voor API-geheimen en gevoelige gegevens die in rust zijn opgeslagen in een HSM of een systeem voor geheimbeheer; tokens in autorisatieheaders, nooit in URL-parameters.

Wat is een LotL (Living off the Land) API-aanval?

Een LotL-aanval maakt gebruik van legitieme, geautoriseerde API-toegang voor kwaadwillige doeleinden. De aanvaller misbruikt geen kwetsbaarheid om toegang te verkrijgen; hij misbruikt de beoogde functionaliteit van een API met behulp van inloggegevens die hij rechtmatig heeft verkregen. Gedragsmonitoring is het belangrijkste detectiemechanisme, omdat op signaturen gebaseerde tools geen onderscheid kunnen maken tussen legitiem en kwaadwillig gebruik van dezelfde API-aanroep.

Welke compliance-frameworks vereisen API-beveiligingsmaatregelen?

Artikel 32 van de AVG vereist technische maatregelen voor de bescherming van persoonsgegevens. De HIPAA-beveiligingsregel vereist toegangscontrole, auditregistratie en beveiliging van de overdracht van elektronische patiëntgegevens. De PCI DSS v4.0-vereisten 4, 6, 7, 8 en 10 zijn van toepassing op API's die kaartgegevens verwerken. De OWASP API Security Top 10 (2023) is de belangrijkste technische referentie voor API-specifieke kwetsbaarheidscategorieën.

Welke invloed hebben post-quantumvereisten op de API-beveiliging?

API's die gevoelige gegevens met een lange levensduur transporteren, lopen een kwantumrisico van HNDL (Harvest Now, Decrypt Later). NIST heeft ML-KEM (FIPS 203) en ML-DSA (FIPS 204) in augustus 2024 definitief vastgesteld. Organisaties zouden hybride TLS-implementaties (ECDHE + ML-KEM) moeten plannen voor zeer gevoelige API's, in lijn met de uitfasering van RSA en ECC in 2030 zoals vastgelegd in NIST IR 8547.