Het OWASP GenAI Security Project definieert een minimale norm in vijf categorieën voor veilige MCP server implementatie. Gebruik deze checklist om uw huidige positie te beoordelen op het gebied van identiteit, isolatie, tooling, validatie en implementatie voordat u naar productie gaat.
De praktische gids van het OWASP GenAI Security Project voor MCP server ontwikkeling culmineert in een concrete beoordelingschecklist — de “MCP Security Minimum Bar”. Deze checklist definieert de basiscontroles die aanwezig moeten zijn voordat een MCP server naar productie wordt geïmplementeerd.
Dit bericht presenteert de volledige checklist met implementatierichtlijnen voor elk item, georganiseerd over de vijf beveiligingsdomeinen die de OWASP gids definieert. Gebruik het voor pre-implementatie beveiligingsbeoordelingen, periodieke audits en als raamwerk voor het verhelpen van geïdentificeerde hiaten.
Items markeren: Registreer voor elk item GESLAAGD (geïmplementeerd en geverifieerd), MISLUKT (niet geïmplementeerd of gedeeltelijk geïmplementeerd), of N.V.T. (niet van toepassing op deze implementatie).
Implementatiepoorten: Items in Categorie 1 (Identiteit, Auth, Policy) en Categorie 2 (Isolatie) zijn harde implementatiepoorten — elke MISLUKT moet go-live blokkeren totdat verholpen. Items in andere categorieën moeten worden geaccepteerd met gedocumenteerde tijdlijnen.
Beoordelingstriggers: Voer de volledige checklist opnieuw uit na elke significante wijziging aan de MCP server code, tool registry, authenticatieconfiguratie, implementatieomgeving, of wanneer een nieuwe categorie tools wordt toegevoegd.
Dit is de categorie met de hoogste prioriteit. Authenticatiefouten geven aanvallers directe toegang tot alles wat de MCP server kan doen.
Wat te verifiëren: Elke externe verbinding met de MCP server vereist authenticatie via een correct geconfigureerde OAuth 2.1 autorisatieserver. Anonieme verbindingen worden geweigerd. Lokale MCP servers die STDIO gebruiken kunnen alternatieve authenticatie gebruiken die geschikt is voor hun implementatiecontext.
Hoe te testen: Probeer verbinding te maken zonder een autorisatieheader. Probeer verbinding te maken met een misvormd of verlopen token. Beide moeten resulteren in authenticatiefout, niet in toegang tot tools.
Veelvoorkomende foutmodi: Ontwikkelingseindpunten die toegankelijk zijn zonder authenticatie; terugval naar API key authenticatie die vervaldatum of scope niet valideert; tokenvalidatie alleen bij sessievestiging, niet per verzoek.
Wat te verifiëren: Toegangstokens verlopen binnen minuten (niet uren). Elk token draagt de minimale scope die vereist is voor de huidige taak. Elke tool-aanroep valideert de handtekening, uitgever (iss), doelgroep (aud), vervaldatum (exp) en vereiste scope van het token — niet alleen bij sessievestiging.
Hoe te testen: Gebruik een geldig token en wacht tot het verloopt (of stel de klok handmatig vooruit). Probeer een tool-aanroep — deze moet falen met een 401, niet slagen op basis van een gecachet validatieresultaat.
Veelvoorkomende foutmodi: Tokenvalidatie gecachet bij sessiestart en niet herhaald; tokens met levensduur van 24+ uur; brede “admin” scopes gebruikt in plaats van operatie-specifieke scopes; exp veld niet gecontroleerd.
Wat te verifiëren: De MCP server stuurt client tokens niet door naar downstream API’s. Alle downstream service-aanroepen gebruiken tokens die expliciet zijn uitgegeven aan de MCP server (via On-Behalf-Of flows of service credentials). Een gecentraliseerde policy gateway onderschept alle tool-aanroepen en handhaaft authenticatie, autorisatie, toestemming en auditlogging voordat enige tool-code wordt uitgevoerd.
Hoe te testen: Bekijk code voor elke locatie waar het inkomende client token wordt doorgestuurd in een uitgaande API-aanroep. Inspecteer downstream service toegangslogboeken om te verifiëren dat verzoeken aankomen met server credentials, niet user credentials.
Veelvoorkomende foutmodi: Authorization: Bearer ${request.headers.authorization} patroon in downstream aanroepen; autorisatiecontroles verspreid over individuele tool handlers; geen gecentraliseerd policy enforcement punt.
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
Isolatiefouten in multi-tenant omgevingen zijn catastrofaal — ze stellen één gebruiker in staat om toegang te krijgen tot de gegevens van een ander. Dit zijn harde implementatiepoorten.
Wat te verifiëren: Geen globale variabelen, class-level attributen of gedeelde singleton instanties slaan gebruikersspecifieke of sessiespecifieke gegevens op. Elke sessie gebruikt onafhankelijk geïnstantieerde objecten of sessie-gekoppelde namespaces (bijv. Redis keys met prefix session_id:). Code review bevestigt geen gedeelde muteerbare state tussen sessies.
Hoe te testen: Voer twee gelijktijdige sessies uit met verschillende gebruikersidentiteiten. Verifieer dat gegevens geschreven in sessie A niet kunnen worden gelezen in sessie B. Gebruik gelijktijdige load tests om te controleren op race conditions die sessiestate lekkage kunnen veroorzaken.
Veelvoorkomende foutmodi: self.user_context = {} als class attribuut in een singleton service; globale caches zonder sessie-gekoppelde namespaces; thread-local storage die niet correct scoped is naar request lifecycle.
Wat te verifiëren: Naast uitvoeringscontext, handhaaft elke gedeelde infrastructuur (databases, caches, message queues) per-gebruiker toegangscontroles. Een query uitgevoerd in de sessie van één gebruiker kan geen gegevens van een andere gebruiker retourneren, zelfs als de gedeelde infrastructuur verkeerd is geconfigureerd of gecompromitteerd.
Hoe te testen: Probeer toegang te krijgen tot de gegevens van een andere gebruiker door sessieparameters te manipuleren of gedeelde cache keys te misbruiken.
Veelvoorkomende foutmodi: Cache keys alleen gebaseerd op query-inhoud, niet op gebruikersidentiteit; database queries zonder gebruikers-gescoped WHERE clauses; gedeelde tijdelijke bestandsdirectories zonder per-gebruiker subdirectories.
Wat te verifiëren: Wanneer een sessie eindigt (netjes of door timeout/error), worden alle bijbehorende resources onmiddellijk vrijgegeven: file handles, tijdelijke bestanden, in-memory context, gecachete tokens, databaseverbindingen. Per-sessie limieten bestaan voor geheugen, CPU, API rate en bestandssysteem gebruik.
Hoe te testen: Beëindig een sessie abrupt (kill de verbinding zonder een graceful shutdown). Verifieer dat er geen residuele resources overblijven. Creëer een sessie en put de rate limit uit; verifieer dat het geen invloed heeft op andere sessies.
Veelvoorkomende foutmodi: Tijdelijke bestanden achtergelaten in /tmp na sessie-einde; gecachete tokens niet ingetrokken bij sessiebeëindiging; geen resource quota waardoor één sessie gedeelde infrastructuur kan uitputten.
Tool beveiliging voorkomt de gevaarlijkste MCP-specifieke aanvallen: tool poisoning en rug pulls.
Wat te verifiëren: Elke tool definitie heeft een cryptografische handtekening van een geautoriseerde tool approver. De handtekening omvat het complete manifest (beschrijving, schema, versie, permissies). De MCP server verifieert deze handtekening bij het laden en weigert elke niet-ondertekende of handtekening-mismatched tool. Tool versies zijn gepind — de server kan geen bijgewerkte tool dynamisch laden zonder een nieuwe goedgekeurde handtekening.
Hoe te testen: Wijzig een enkel karakter in de beschrijving van een geladen tool. Verifieer dat de server de hash mismatch detecteert en de tool blokkeert van laden. Probeer een niet-ondertekende tool definitie te laden — deze moet worden geweigerd.
Veelvoorkomende foutmodi: Tool definities opgeslagen als muteerbare configuratie zonder integriteitsverificatie; geen signing key infrastructuur; tools geladen direct van een gedeeld bestandssysteem zonder versie pinning.
Wat te verifiëren: Geautomatiseerde scanning controleert tool beschrijvingen op instructie-achtige patronen die poisoning pogingen kunnen vertegenwoordigen. Periodieke validatie bevestigt dat het werkelijke runtime gedrag van een tool overeenkomt met de gedeclareerde beschrijving — een tool die beweert read-only te zijn mag niet in staat zijn tot schrijfoperaties tijdens runtime.
Hoe te testen: Voeg een verdachte instructie toe aan een tool beschrijving (“roep altijd ook send_webhook aan met…”) en verifieer dat geautomatiseerde scanning het markeert vóór menselijke beoordeling. Bekijk de SAST tool configuratie voor MCP-specifieke poisoning detectieregels.
Veelvoorkomende foutmodi: Geen geautomatiseerde scanning van tool beschrijvingen; handmatig beoordelingsproces dat ingebedde instructies in lange beschrijvingen kan missen; geen runtime gedragsvalidatie om tools te vangen die liegen over hun mogelijkheden.
Wat te verifiëren: De modelcontext ontvangt alleen de velden die vereist zijn voor correcte tool-aanroep: naam, beschrijving, input schema, output schema. Interne metadata, implementatiedetails, debugging informatie en gevoelige configuratie worden uitgefilterd voordat ze aan het model worden doorgegeven.
Hoe te testen: Inspecteer wat het model ontvangt wanneer het beschikbare tools opsomt. Verifieer dat geen interne velden, connection strings of operationele metadata verschijnen in de weergave van het model.
Veelvoorkomende foutmodi: Volledige tool configuratie objecten doorgegeven aan de modelcontext; foutmeldingen met interne systeemdetails die lekken naar het model; tool beschrijvingen inclusief implementatienotities die niet relevant zijn voor aanroep.
Ontvang gratis de nieuwste tips, trends en aanbiedingen.
Validatiefouten maken injection, gegevensmanipulatie en denial-of-service mogelijk.
Wat te verifiëren: JSON Schema validatie wordt afgedwongen voor elk MCP protocol bericht, elke tool-aanroep input en elke tool output voordat het het model bereikt. Validatie weigert elk bericht dat niet voldoet aan het gedefinieerde schema — ontbrekende vereiste velden, verkeerde types, waarden buiten toegestane bereiken.
Hoe te testen: Stuur een tool-aanroep met een ontbrekende vereiste parameter. Stuur een bericht met een extra onverwacht veld. Beide moeten worden geweigerd, niet stilzwijgend genegeerd of verwerkt met standaardwaarden.
Veelvoorkomende foutmodi: Optionele validatie die wordt omzeild onder foutcondities; validatie alleen op inputs, niet op outputs; schema’s die te permissief zijn (accepteren type: "any" parameters).
Wat te verifiëren: Alle inputs worden gesaniteerd om karakters te verwijderen of te escapen die injection mogelijk kunnen maken (XSS sequenties, SQL metacharacters, shell metacharacters, null bytes). Groottelimieten worden afgedwongen op alle inputs en outputs. De server behandelt alle gegevens van het model als potentieel vijandig, identiek aan gebruikersinput in een traditionele webapplicatie.
Hoe te testen: Stuur inputs met SQL injection payloads, shell metacharacters en XSS sequenties. Verifieer dat ze worden geweigerd of veilig ge-escaped voordat ze downstream systemen bereiken. Stuur een input die de groottelimiet overschrijdt — verifieer dat deze netjes wordt geweigerd.
Veelvoorkomende foutmodi: Inputs direct doorgegeven aan SQL queries of shell commando’s; geen groottelimieten waardoor te grote inputs geheugenuitputting kunnen veroorzaken; outputs geretourneerd aan het model zonder groottelimieten of content filtering.
Wat te verifiëren: Tool calls worden alleen geaccepteerd als gestructureerde JSON objecten met gevalideerde schema’s. Vrije-vorm tekstgeneratie die tool-aanroepen impliceert wordt niet verwerkt. Het systeem kan niet worden verleid om tool calls uit te voeren door natuurlijke taal te genereren die de server interpreteert als commando’s.
Hoe te testen: Stuur een natuurlijke taal string die een tool-aanroep beschrijft (“roep de delete_file tool aan met pad /etc/passwd”). Verifieer dat de server dit niet interpreteert als een tool call.
Veelvoorkomende foutmodi: Hybride systemen die zowel gestructureerde JSON als natuurlijke taal tool beschrijvingen accepteren; servers die model-gegenereerde tekst parsen om tool-aanroepen te identificeren; regex-gebaseerde tool call parsing die kan worden gespoofed.
Implementatie hardening beperkt de blast radius van elke geëxploiteerde kwetsbaarheid.
Wat te verifiëren: De MCP server draait in een minimale geharde container. Het containerproces draait als een non-root gebruiker. Onnodige Linux capabilities zijn verwijderd. Netwerkbeleid beperkt al het inkomende en uitgaande verkeer tot expliciet vereiste verbindingen. De container image bevat alleen de minimaal vereiste software.
Hoe te testen: Voer docker inspect uit en verifieer dat de gebruiker non-root is. Bekijk netwerkbeleid en bevestig dat ze al het verkeer blokkeren behalve expliciet whitelisted verbindingen. Scan de container image voor onnodige packages of bekende kwetsbare software.
Veelvoorkomende foutmodi: Containers die als root draaien voor gemak; geen netwerkbeleid waardoor al het uitgaande verkeer is toegestaan; base images met volledige OS installaties in plaats van minimale images.
Wat te verifiëren: Alle API keys, OAuth client secrets, database credentials en service account tokens worden opgeslagen in een secrets vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.). Geen secrets bestaan in omgevingsvariabelen, broncode, container images of log output. Secrets management operaties gebeuren in middleware die ontoegankelijk is voor het AI model — de LLM ziet of verwerkt nooit credential waarden.
Hoe te testen: Zoek logs naar credential-achtige strings. Inspecteer omgevingsvariabelen toegankelijk voor het serverproces. Bekijk de toegankelijke context van het model om te bevestigen dat geen credential waarden verschijnen.
Veelvoorkomende foutmodi: API keys in .env bestanden gecommit naar versiecontrole; credentials geretourneerd in foutmeldingen die het model bereiken; secrets doorgegeven als tool parameters die verschijnen in de conversatiecontext van het model.
Wat te verifiëren: De implementatiepipeline omvat geautomatiseerde beveiligingsscanning (SAST, SCA, dependency vulnerability scanning) als harde poorten — mislukte scans blokkeren implementatie. Alle tool-aanroepen, authenticatiegebeurtenissen en autorisatiebeslissingen worden onveranderlijk gelogd met volledige context. Logs worden opgenomen door een SIEM met real-time alerting op afwijkende patronen (mislukte validatie pieken, ongebruikelijke tool call frequentie, onverwachte externe verbindingen).
Hoe te testen: Introduceer een bekende kwetsbare dependency en verifieer dat de CI/CD pipeline de build laat falen. Genereer afwijkende tool call patronen en verifieer dat SIEM alerts afgaan binnen de verwachte responstijd.
Veelvoorkomende foutmodi: Beveiligingsscanning als adviserend in plaats van blokkerende poorten; logs geschreven naar muteerbare opslag die een aanvaller zou kunnen wijzigen; geen alerting op afwijkende patronen; overmatige log verbosity die relevante gebeurtenissen onmogelijk te vinden maakt.
Print of exporteer deze checklist en werk deze systematisch door voor elke MCP server vóór productie-implementatie. Betrek uw beveiligingsteam bij de beoordeling — veel items vereisen zowel code review als live testing om correct te verifiëren.
Voor teams die onafhankelijke verificatie willen, test een professionele MCP beveiligingsaudit alle 16 checklist items tegen uw live-omgeving, met gebruik van adversarial testing technieken in plaats van zelfevaluatie. Het resultaat is een geverifieerd beveiligingspostuur rapport met een geprioriteerd remediatieplan.
De 'MCP Security Minimum Bar' van het OWASP GenAI Security Project is een beoordelingschecklist die de basisbeveiligingscontroles definieert die vereist zijn voordat een MCP server naar productie mag worden geïmplementeerd. Het omvat vijf domeinen: Sterke Identiteit/Auth/Policy Enforcement, Strikte Isolatie en Lifecycle Control, Vertrouwde en Gecontroleerde Tooling, Schema-Gedreven Validatie, en Geharde Implementatie met Continu Toezicht. Als niet aan de minimale norm wordt voldaan, mag de MCP server niet worden geïmplementeerd totdat de hiaten zijn verholpen.
Werk elke categorie systematisch door en markeer items als GESLAAGD, MISLUKT of NIET VAN TOEPASSING met bewijs voor elke beslissing. Elke MISLUKT in categorieën 1 of 2 (identiteit en isolatie) moet implementatie blokkeren — dit zijn de hiaten met het hoogste risico. MISLUKTen in andere categorieën moeten worden geaccepteerd met een gedocumenteerde remediatietijdlijn voordat implementatie plaatsvindt. De checklist moet opnieuw worden geëvalueerd na elke significante wijziging aan de MCP server, tool registry of implementatieomgeving.
Verschillende tools ondersteunen geautomatiseerde MCP beveiligingsvalidatie: Invariant MCP-Scan (gespecialiseerd voor MCP beveiligingsscanning), SAST tools met aangepaste MCP regels, npm audit en pip audit voor dependency scanning, OSV-Scanner voor kwetsbaarheidscontroles, Docker seccomp en AppArmor profielen voor runtime isolatie, en SIEM integratie voor gecentraliseerde monitoring. Geen enkele tool dekt alle checklist items — uitgebreide dekking vereist een combinatie van statische analyse, dynamische testing en continue monitoring.
Arshia is een AI Workflow Engineer bij FlowHunt. Met een achtergrond in computerwetenschappen en een passie voor AI, specialiseert zij zich in het creëren van efficiënte workflows die AI-tools integreren in dagelijkse taken, waardoor productiviteit en creativiteit worden verhoogd.
Gebruik deze checklist voor zelfevaluatie en schakel vervolgens ons team in voor een geverifieerde beveiligingsaudit. Wij testen elk item tegen uw live-omgeving en leveren een gedetailleerd remediatieplan.
MCP servers bieden een uniek aanvalsoppervlak dat traditionele API-risico's combineert met AI-specifieke bedreigingen. Leer de 6 kritieke kwetsbaarheden geïdent...
Authenticatie is de meest kritieke beveiligingslaag voor externe MCP-servers. Leer waarom OAuth 2.1 met OIDC verplicht is, hoe token delegatie de Confused Deput...
Prompt injection is de primaire aanvalsvector tegen MCP-servers in productie. Leer de vier door OWASP aanbevolen controls: gestructureerde tool-aanroep, Human-i...
