Het AI-API-ecosysteem
Een gids voor de redteamer door het AI-API-landschap — OpenAI, Anthropic, Google, AWS, Azure, open-source API's, authenticatiepatronen en veelvoorkomende beveiligingsmisconfiguraties.
De API als aanvalsoppervlak
De meeste AI-applicaties communiceren niet rechtstreeks met modellen — ze roepen API's aan. Deze API's zijn de poortwachters tussen gebruikersinvoer en model-inference en verzorgen authenticatie, rate limiting, invoervalidatie en het formatteren van responses. Voor redteamers is de API-laag vaak het eerste contactpunt en een rijke bron van kwetsbaarheden.
API's van de grote aanbieders
OpenAI-API
De meest gebruikte AI-API, die GPT-4, GPT-4o, o1, o3, DALL-E en Whisper aandrijft.
| Aspect | Details |
|---|---|
| Authenticatie | Bearer token (sk-... API-sleutels) |
| Rate limiting | Per organisatie, getrapt op basis van het gebruiksplan |
| Endpoints | /v1/chat/completions, /v1/embeddings, /v1/images/generations, /v1/audio |
| Opvallende functies | Function calling, JSON-modus, streaming, logprobs, moderation-endpoint |
| Beveiligingsrelevant | De moderation-API draait los van completions; tool use vergroot het aanvalsoppervlak |
Notities voor het red team: OpenAI-API-sleutels volgen een voorspelbaar formaat (sk-proj-... voor projectsleutels, sk-... voor legacy-sleutels). Het moderation-endpoint kun je apart testen om te begrijpen wat het contentfilter tegenhoudt. Function calling introduceert gestructureerde output die op tekst gebaseerde outputfilters omzeilt.
Anthropic-API
Drijft de Claude-modellen aan, met een focus op veiligheid en constitutional AI.
| Aspect | Details |
|---|---|
| Authenticatie | API-sleutel in header (x-api-key) |
| Rate limiting | Per sleutel, met aparte limieten voor input- en output-tokens |
| Endpoints | /v1/messages, /v1/complete (legacy) |
| Opvallende functies | System prompt als aparte parameter, tool use, streaming, vision |
| Beveiligingsrelevant | De system prompt wordt als eersteklas parameter behandeld (niet slechts als een berichtrol) |
Notities voor het red team: De system prompt-architectuur van Anthropic scheidt systeeminstructies duidelijker van de berichtgeschiedenis dan andere aanbieders. De rate limits maken onderscheid tussen input- en output-tokens, wat invloed heeft op je strategieën voor extractie-aanvallen.
Google AI-API's
Drijft de Gemini-modellen aan via zowel een directe API als Google Cloud Vertex AI.
| Aspect | Details |
|---|---|
| Authenticatie | API-sleutel (direct) of OAuth/service-account (Vertex AI) |
| Rate limiting | Quota per project in Google Cloud |
| Endpoints | generativelanguage.googleapis.com, Vertex AI-endpoints |
| Opvallende functies | Grounding met Google Search, code-uitvoering, multimodaal (tekst, beeld, video, audio) |
| Beveiligingsrelevant | Grounding met Google Search introduceert indirecte injectie via webcontent |
Notities voor het red team: De grounding-functie van Gemini, die verbinding maakt met Google Search, introduceert een belangrijke vector voor indirecte prompt injection — webpagina's die tijdens grounding worden opgehaald, kunnen adversarial instructies bevatten. Het dubbele API-oppervlak (direct en Vertex) kan verschillende beveiligingsconfiguraties hebben.
AWS Bedrock
Amazons managed dienst die via één uniforme API toegang biedt tot meerdere modelaanbieders.
| Aspect | Details |
|---|---|
| Authenticatie | AWS IAM (Signature V4) |
| Rate limiting | Provisioned throughput of on-demand met accountlimieten |
| Endpoints | bedrock-runtime.\{region\}.amazonaws.com |
| Opvallende functies | Toegang tot meerdere modellen (Claude, Llama, Mistral, Titan), Guardrails-API, Knowledge Bases |
| Beveiligingsrelevant | IAM-policies kunnen verkeerd geconfigureerd zijn; de Guardrails-API is een aparte laag |
Notities voor het red team: AWS Bedrock verpakt meerdere modelaanbieders achter AWS IAM-authenticatie. Verkeerd geconfigureerde IAM-policies (te ruime bedrock:InvokeModel-rechten) komen vaak voor. De Bedrock Guardrails-API voegt een door de aanbieder beheerde guardrail-laag toe die losstaat van de veiligheid van het individuele model.
Azure OpenAI Service
Microsofts enterprise-deployment van OpenAI-modellen via de Azure-infrastructuur.
| Aspect | Details |
|---|---|
| Authenticatie | API-sleutel of Azure AD-token (Entra ID) |
| Rate limiting | Per deployment, configureerbaar |
| Endpoints | \{resource-name\}.openai.azure.com |
| Opvallende functies | Contentfiltering standaard ingeschakeld, ondersteuning voor privénetwerken, managed identity |
| Beveiligingsrelevant | De filters van Azure Content Safety staan los van OpenAI's moderation en kunnen onafhankelijk worden geconfigureerd |
Notities voor het red team: Azure OpenAI heeft een eigen contentfilterlaag (Azure Content Safety) die naast OpenAI's ingebouwde veiligheid draait. Dit betekent dat omzeilen het ontwijken van beide lagen vereist. De configuratie van het contentfilter staat echter in de Azure-portal, en bij verkeerd geconfigureerde deployments kunnen de filters uitgeschakeld zijn.
Authenticatiepatronen en kwetsbaarheden
Authenticatie met API-sleutel
Het eenvoudigste en meest voorkomende patroon. Een geheime sleutel wordt in elke aanvraag meegestuurd.
Veelvoorkomende kwetsbaarheden:
- Sleutels hardcoded in client-side JavaScript
- Sleutels gecommit naar publieke Git-repositories
- Sleutels opgeslagen in omgevingsvariabelen die uitlekken via foutpagina's of server-status-endpoints
- Geen sleutelrotatiebeleid — gecompromitteerde sleutels blijven onbeperkt geldig
- Te ruim ingestelde sleutels die toegang geven tot alle modellen en endpoints
Authenticatie via OAuth / service-account
Veiliger, maar complexer. Gebruikt door Google Cloud, Azure AD en enterprise-deployments.
Veelvoorkomende kwetsbaarheden:
- Te ruime rechten voor service-accounts
- Token-refresh-endpoints zonder goede toegangscontroles
- Langlevende tokens die onveilig worden opgeslagen
- Ontbrekende audience- of scope-validatie bij tokenverificatie
Geen authenticatie
Sommige self-hosted deployments en ontwikkel-endpoints draaien zonder authenticatie.
Veelvoorkomende kwetsbaarheden:
- Interne endpoints die via verkeerd geconfigureerde load balancers of netwerkbeleid worden blootgesteld
- Ontwikkeldeployments die in productie blijven draaien
- Model-inference-endpoints die binnen een VPC toegankelijk zijn maar niet goed gesegmenteerd
API-proxying en -aggregatie
Veel applicaties roepen de API's van aanbieders niet rechtstreeks aan. In plaats daarvan gebruiken ze proxylagen of aggregatiediensten die extra aanvalsoppervlak introduceren.
Veelvoorkomende proxypatronen
| Patroon | Beschrijving | Beveiligingsimplicatie |
|---|---|---|
| Backend-proxy | De backend van de applicatie stuurt aanvragen door naar de AI-aanbieder | De proxy kan veiligheidsheaders strippen of aanpassen; logging kan gevoelige data vastleggen |
| API-gateway | Een gateway (Kong, Apigee) staat voor de AI-API | Verkeerd geconfigureerde gateways kunnen header-injectie toestaan of rate limiting omzeilen |
| Aggregatordienst | Diensten als OpenRouter of LiteLLM bieden één API voor meerdere aanbieders | De aggregator heeft toegang tot alle aanvragen; hij voegt een vertrouwensgrens toe |
| Cachinglaag | Responses worden gecachet om kosten en latency te verlagen | Cachevergiftiging kan adversarial responses aan andere gebruikers serveren |
Proxy-specifieke kwetsbaarheden
- System prompt-injectie via headers: Sommige proxy-implementaties geven system prompts door via custom headers die de client kan overschrijven
- Sleutelblootstelling via proxies: De proxy houdt de API-sleutel van de aanbieder vast; compromittering van de proxy stelt de sleutel bloot
- Inconsistent beveiligingsbeleid: De proxy kan andere rate limits of contentfilters hanteren dan de onderliggende aanbieder
- Logging van aanvragen/responses: Proxies kunnen volledige request- en response-bodies loggen, wat een vector voor datalekken creëert
Verschillen in API-ontwerp die aanvallen beïnvloeden
Subtiele verschillen in hoe aanbieders hun API's implementeren, creëren aanbieder-specifieke aanvalskansen:
| Functie | Variatie | Beveiligingsimpact |
|---|---|---|
| System prompt | Aparte parameter vs. eerste bericht | Beïnvloedt strategieën voor prompt injection |
| Tokens tellen | Verschillende tokenizers leveren verschillende aantallen op | Beïnvloedt aanvallen die op het contextvenster mikken |
| Streaming | SSE vs. WebSocket vs. chunked transfer | Streaming kan filters voor na-verwerking omzeilen |
| Foutmeldingen | Uitgebreid vs. generiek | Uitgebreide fouten lekken informatie over model en configuratie |
| Function calling | Verschillende schema's en validatie | Gaten in schemavalidatie maken injectie via toolargumenten mogelijk |
| Moderation | Apart endpoint vs. inline | Aparte endpoints kun je onafhankelijk testen |
Veelvoorkomende API-beveiligingsmisconfiguraties
Op basis van red team-bevindingen uit de praktijk zijn dit de meest waargenomen API-beveiligingsproblemen in AI-applicaties:
- Blootgestelde API-sleutels in client-side code — de frontend van de applicatie bevat de API-sleutel van de AI-aanbieder, wat directe toegang mogelijk maakt
- Ontbrekende rate limiting op de eigen API van de applicatie — ook als de aanbieder rate limits hanteert, doet het endpoint van de applicatie dat misschien niet
- Geen lengtevalidatie van invoer — willekeurig lange invoer accepteren maakt contextvensteraanvallen en kostenmisbruik mogelijk
- Uitgebreide foutmeldingen — foutresponses die de modelnaam, fragmenten van de system prompt of infrastructuurdetails onthullen
- Inconsistente endpoint-beveiliging — het hoofd-chatendpoint is beveiligd, maar alternatieve endpoints (embedding, moderation, completion) niet
- Ontbrekende outputvalidatie — modelresponses worden zonder sanitatie rechtstreeks aan de gebruiker teruggegeven
- Gedeelde API-sleutels — één API-sleutel die wordt gebruikt voor alle omgevingen (dev, staging, productie) en alle functies
- Geen audit-logging — geen registratie van welke queries naar het model zijn gestuurd, waardoor incidentafhandeling onmogelijk wordt
Gerelateerde onderwerpen
- Het AI-landschap — bredere context van aanbieders en platformen
- Deploymentpatronen — hoe deployment de API-beveiliging beïnvloedt
- AI-systeemarchitectuur — diepere duik in API-architectuur
- Guardrails-architectuur — hoe guardrails integreren met API's
Bronnen
- "OpenAI API Reference" - OpenAI (2025) - Volledige documentatie van de OpenAI-API, inclusief authenticatie, endpoints en parameters
- "Anthropic API Documentation" - Anthropic (2025) - Documentatie van de Claude-API, inclusief de afhandeling van de system prompt en rate limiting
- "OWASP API Security Top 10" - OWASP (2023) - Standaardclassificatie van API-beveiligingsrisico's die van toepassing is op AI-API-implementaties
- "Exposed ML Model Servers on the Internet" - ProtectAI (2025) - Onderzoek naar publiek toegankelijke AI-inference-endpoints die via internetscans zijn ontdekt
Wat is de meest voorkomende API-beveiligingskwetsbaarheid in AI-applicaties in de praktijk?