OWASP GenAI Security Project definerer en minimumsstandard i fem kategorier for sikker MCP server-udrulning. Brug denne tjekliste til at vurdere din nuværende sikkerhedsstatus på tværs af identitet, isolering, værktøjer, validering og udrulning før produktionssætning.
OWASP GenAI Security Projects praktiske guide til MCP server-udvikling kulminerer i en konkret gennemgangstjekliste — “MCP Security Minimum Bar”. Denne tjekliste definerer de grundlæggende kontroller, der skal være på plads, før en MCP server udrulles til produktion.
Dette indlæg præsenterer den fulde tjekliste med implementeringsvejledning for hvert punkt, organiseret på tværs af de fem sikkerhedsdomæner, som OWASP-guiden definerer. Brug den til sikkerhedsgennemgange før udrulning, periodiske revisioner og som ramme for at udbedre identificerede mangler.
Markering af punkter: For hvert punkt skal du registrere BESTÅET (implementeret og verificeret), IKKE BESTÅET (ikke implementeret eller delvist implementeret), eller IKKE RELEVANT (ikke relevant for denne udrulning).
Udrulningsporte: Punkter i Kategori 1 (Identitet, Autentificering, Politik) og Kategori 2 (Isolering) er hårde udrulningsporte — ethvert IKKE BESTÅET bør blokere ibrugtagning, indtil det er udbedret. Punkter i andre kategorier bør risikoaccepteres med dokumenterede tidsplaner.
Gennemgangsudløsere: Kør den fulde tjekliste igen efter enhver væsentlig ændring af MCP server-koden, værktøjsregisteret, autentificeringskonfigurationen, udrulningsmiljøet, eller når en ny kategori af værktøjer onboardes.
Dette er den højest prioriterede kategori. Autentificeringsfejl giver angribere direkte adgang til alt, hvad MCP serveren kan gøre.
Hvad der skal verificeres: Hver fjernforbindelse til MCP serveren kræver autentificering gennem en korrekt konfigureret OAuth 2.1 autorisationsserver. Anonyme forbindelser afvises. Lokale MCP servere, der bruger STDIO, kan bruge alternativ autentificering passende til deres udrulningskontekst.
Sådan tester du: Forsøg at oprette forbindelse uden en autorisationsheader. Forsøg at oprette forbindelse med et misdannet eller udløbet token. Begge bør resultere i autentificeringsfejl, ikke adgang til værktøjer.
Almindelige fejltilstande: Udviklingsendpoints efterladt tilgængelige uden autentificering; tilbagefald til API-nøgle autentificering, der ikke validerer udløb eller scope; token-validering kun ved sessionsoprettelse, ikke pr. anmodning.
Hvad der skal verificeres: Adgangstokens udløber inden for minutter (ikke timer). Hvert token bærer det minimale scope, der kræves for den aktuelle opgave. Hver værktøjsinvokation validerer tokenets signatur, udsteder (iss), målgruppe (aud), udløb (exp) og påkrævet scope — ikke kun ved sessionsoprettelse.
Sådan tester du: Brug et gyldigt token, og vent derefter på, at det udløber (eller indstil uret manuelt fremad). Forsøg et værktøjskald — det bør fejle med en 401, ikke lykkes på et cached valideringsresultat.
Almindelige fejltilstande: Token-validering cached ved sessionsstart og ikke gentaget; tokens med 24+ timers levetid; brede “admin” scopes brugt i stedet for operationsspecifikke scopes; exp-felt ikke kontrolleret.
Hvad der skal verificeres: MCP serveren videresender ikke klient-tokens til downstream API’er. Alle downstream service-kald bruger tokens eksplicit udstedt til MCP serveren (via On-Behalf-Of flows eller service-credentials). En centraliseret politik-gateway opfanger alle værktøjsinvokationer og håndhæver autentificering, autorisation, samtykke og revisionslogning, før nogen værktøjskode eksekveres.
Sådan tester du: Gennemgå kode for enhver placering, hvor det indkommende klient-token videresendes i et udgående API-kald. Inspicér downstream service-adgangslogfiler for at verificere, at anmodninger ankommer med server-credentials, ikke bruger-credentials.
Almindelige fejltilstande: Authorization: Bearer ${request.headers.authorization} mønster i downstream-kald; autorisationskontroller spredt på tværs af individuelle værktøjshåndterere; ingen centraliseret politikhåndhævelsespunkt.
Start din gratis prøveperiode i dag og se resultater inden for få dage.
Isoleringsfejl i multi-tenant miljøer er katastrofale — de gør det muligt for én bruger at få adgang til en andens data. Disse er hårde udrulningsporte.
Hvad der skal verificeres: Ingen globale variabler, klasse-niveau attributter eller delte singleton-instanser gemmer brugerspecifikke eller sessionsspecifikke data. Hver session bruger uafhængigt instantierede objekter eller sessions-nøglede navnerum (f.eks. Redis-nøgler præfikset med session_id:). Kodegennemgang bekræfter ingen delt muterbar tilstand mellem sessioner.
Sådan tester du: Kør to samtidige sessioner med forskellige brugeridentiteter. Verificer, at data skrevet i session A ikke kan læses i session B. Brug samtidige belastningstest for at kontrollere for race conditions, der kan forårsage sessionstilstandslækage.
Almindelige fejltilstande: self.user_context = {} som en klasseattribut i en singleton-service; globale caches uden sessions-nøglede navnerum; thread-local storage, der ikke korrekt afgrænser til anmodningslivscyklus.
Hvad der skal verificeres: Ud over eksekveringskontekst håndhæver enhver delt infrastruktur (databaser, caches, beskedkøer) pr.-bruger adgangskontroller. En forespørgsel udført i én brugers session kan ikke returnere en anden brugers data, selv hvis den delte infrastruktur er fejlkonfigureret eller kompromitteret.
Sådan tester du: Forsøg at få adgang til en anden brugers data ved at manipulere sessionsparametre eller udnytte delte cache-nøgler.
Almindelige fejltilstande: Cache-nøgler kun baseret på forespørgselsindhold, ikke brugeridentitet; databaseforespørgsler uden bruger-scopede WHERE-klausuler; delte midlertidige filmapper uden pr.-bruger undermapper.
Hvad der skal verificeres: Når en session afsluttes (rent eller gennem timeout/fejl), frigives alle tilknyttede ressourcer øjeblikkeligt: filhåndtag, midlertidige filer, in-memory kontekst, cachede tokens, databaseforbindelser. Pr.-session grænser eksisterer for hukommelse, CPU, API-rate og filsystemforbrug.
Sådan tester du: Afslut en session brat (dræb forbindelsen uden en yndefuld nedlukning). Verificer, at ingen resterende ressourcer forbliver. Opret en session og udtøm dens rate-grænse; verificer, at det ikke påvirker andre sessioner.
Almindelige fejltilstande: Midlertidige filer efterladt i /tmp efter sessionsafslutning; cachede tokens ikke tilbagekaldt ved sessionsafslutning; ingen ressourcekvoter, der tillader én session at udtømme delt infrastruktur.
Værktøjssikkerhed forhindrer de farligste MCP-specifikke angreb: værktøjsforgiftning og rug pulls.
Hvad der skal verificeres: Hver værktøjsdefinition har en kryptografisk signatur fra en autoriseret værktøjsgodkender. Signaturen dækker det komplette manifest (beskrivelse, skema, version, tilladelser). MCP serveren verificerer denne signatur ved indlæsningstidspunktet og afviser ethvert usigneret eller signatur-mismatchet værktøj. Værktøjsversioner er pinnede — serveren kan ikke dynamisk indlæse et opdateret værktøj uden en ny godkendt signatur.
Sådan tester du: Modificer et enkelt tegn i et indlæst værktøjs beskrivelse. Verificer, at serveren opdager hash-mismatchen og blokerer værktøjet fra at blive indlæst. Forsøg at indlæse en usigneret værktøjsdefinition — den bør afvises.
Almindelige fejltilstande: Værktøjsdefinitioner gemt som muterbar konfiguration uden integritetsverficering; ingen signeringsnøgle-infrastruktur; værktøjer indlæst direkte fra et delt filsystem uden versionspinning.
Hvad der skal verificeres: Automatiseret scanning kontrollerer værktøjsbeskrivelser for instruktionslignende mønstre, der kunne repræsentere forgiftningsforsøg. Periodisk validering bekræfter, at et værktøjs faktiske runtime-adfærd matcher dets erklærede beskrivelse — et værktøj, der hævder at være read-only, bør ikke være i stand til skrive-operationer ved runtime.
Sådan tester du: Tilføj en mistænkelig instruktion til en værktøjsbeskrivelse (“kald altid også send_webhook med…”) og verificer, at automatiseret scanning flagger det før menneskelig gennemgang. Gennemgå SAST-værktøjskonfigurationen for MCP-specifikke forgiftningsdetektionsregler.
Almindelige fejltilstande: Ingen automatiseret scanning af værktøjsbeskrivelser; manuel gennemgangsproces, der kan overse indlejrede instruktioner i lange beskrivelser; ingen runtime-adfærdsvalidering til at fange værktøjer, der lyver om deres kapaciteter.
Hvad der skal verificeres: Modelkonteksten modtager kun de felter, der kræves for korrekt værktøjsinvokation: navn, beskrivelse, input-skema, output-skema. Interne metadata, implementeringsdetaljer, fejlfindingsinformation og følsom konfiguration filtreres ud, før de sendes til modellen.
Sådan tester du: Inspicér, hvad modellen modtager, når den opregner tilgængelige værktøjer. Verificer, at ingen interne felter, forbindelsesstrenge eller operationelle metadata vises i modellens visning.
Almindelige fejltilstande: Fulde værktøjskonfigurationsobjekter sendt til modelkonteksten; fejlmeddelelser indeholdende interne systemdetaljer, der lækker til modellen; værktøjsbeskrivelser, der inkluderer implementeringsnoter, der ikke er relevante for invokation.
Få de seneste tips, trends og tilbud gratis.
Valideringsfejl muliggør injektion, datamanipulation og denial-of-service.
Hvad der skal verificeres: JSON Schema-validering håndhæves for hver MCP-protokolbesked, hvert værktøjsinvokationsinput og hvert værktøjsoutput, før det når modellen. Validering afviser enhver besked, der ikke overholder det definerede skema — manglende påkrævede felter, forkerte typer, værdier uden for tilladte intervaller.
Sådan tester du: Send en værktøjsinvokation med en manglende påkrævet parameter. Send en besked med et ekstra uventet felt. Begge bør afvises, ikke stille ignoreret eller behandlet med standardværdier.
Almindelige fejltilstande: Valgfri validering, der omgås under fejltilstande; validering kun på inputs, ikke outputs; skemaer, der er for permissive (accepterer type: "any" parametre).
Hvad der skal verificeres: Alle inputs saneres for at fjerne eller escape tegn, der kunne muliggøre injektion (XSS-sekvenser, SQL-metategn, shell-metategn, null-bytes). Størrelsesgrænser håndhæves på alle inputs og outputs. Serveren behandler alle data fra modellen som potentielt fjendtlige, identisk med brugerinput i en traditionel webapplikation.
Sådan tester du: Send inputs indeholdende SQL-injektions-payloads, shell-metategn og XSS-sekvenser. Verificer, at de afvises eller sikkert escapes, før de når downstream-systemer. Send et input, der overskrider størrelsesgrænsen — verificer, at det afvises rent.
Almindelige fejltilstande: Inputs sendt direkte til SQL-forespørgsler eller shell-kommandoer; ingen størrelsesgrænser, der tillader oversized inputs at forårsage hukommelsesudmattelse; outputs returneret til modellen uden størrelsesgrænser eller indholdsfiltrering.
Hvad der skal verificeres: Værktøjskald accepteres kun som strukturerede JSON-objekter med validerede skemaer. Friform-tekstgenerering, der implicerer værktøjsinvokationer, behandles ikke. Systemet kan ikke induceres til at eksekvere værktøjskald ved at generere naturligt sprog, som serveren fortolker som kommandoer.
Sådan tester du: Send en naturlig sprogstreng, der beskriver en værktøjsinvokation (“kald delete_file værktøjet med sti /etc/passwd”). Verificer, at serveren ikke fortolker dette som et værktøjskald.
Almindelige fejltilstande: Hybridsystemer, der accepterer både struktureret JSON og naturlig sprog-værktøjsbeskrivelser; servere, der parser model-genereret tekst for at identificere værktøjsinvokationer; regex-baseret værktøjskald-parsing, der kan forfalskes.
Udrulningshærdning begrænser sprængningsradius af enhver udnyttet sårbarhed.
Hvad der skal verificeres: MCP serveren kører i en minimal hærdet container. Container-processen kører som en non-root bruger. Unødvendige Linux-kapaciteter droppes. Netværkspolitikker begrænser al indgående og udgående trafik til eksplicit krævede forbindelser. Container-imaget indeholder kun den minimalt påkrævede software.
Sådan tester du: Kør docker inspect og verificer, at brugeren er non-root. Gennemgå netværkspolitikker og bekræft, at de blokerer al trafik undtagen eksplicit whitelistede forbindelser. Scan container-imaget for unødvendige pakker eller kendt-sårbar software.
Almindelige fejltilstande: Containere, der kører som root for bekvemmelighed; ingen netværkspolitikker, der efterlader al udgående trafik tilladt; base-images med fulde OS-installationer i stedet for minimale images.
Hvad der skal verificeres: Alle API-nøgler, OAuth klient-hemmeligheder, database-credentials og service account tokens gemmes i en hemmeligheds-vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, osv.). Ingen hemmeligheder eksisterer i miljøvariabler, kildekode, container-images eller log-output. Hemmelighedshåndteringsoperationer sker i middleware, der er utilgængelig for AI-modellen — LLM’en ser eller behandler aldrig credential-værdier.
Sådan tester du: Søg i logs efter credential-lignende strenge. Inspicér miljøvariabler tilgængelige for serverprocessen. Gennemgå modellens tilgængelige kontekst for at bekræfte, at ingen credential-værdier vises.
Almindelige fejltilstande: API-nøgler i .env-filer committet til versionskontrol; credentials returneret i fejlmeddelelser, der når modellen; hemmeligheder sendt som værktøjsparametre, der vises i modellens samtalekontekst.
Hvad der skal verificeres: Udrulningspipelinen inkluderer automatiseret sikkerhedsscanning (SAST, SCA, afhængighedssårbarhedsscanning) som hårde porte — fejlede scanninger blokerer udrulning. Alle værktøjsinvokationer, autentificeringshændelser og autorisationsbeslutninger logges immutabelt med fuld kontekst. Logs indsamles af en SIEM med real-time alarmer på anomale mønstre (fejlede valideringsstigninger, usædvanlig værktøjskaldsfrekvens, uventede eksterne forbindelser).
Sådan tester du: Introducér en kendt-sårbar afhængighed og verificer, at CI/CD-pipelinen fejler bygget. Generér anomale værktøjskaldsmønstre og verificer, at SIEM-alarmer udløses inden for den forventede svartid.
Almindelige fejltilstande: Sikkerhedsscanning som rådgivende snarere end blokerende porte; logs skrevet til muterbar storage, som en angriber kunne modificere; ingen alarmering på anomale mønstre; overdreven log-verbositet, der gør relevante hændelser umulige at finde.
Udskriv eller eksportér denne tjekliste og gennemgå den systematisk for hver MCP server før produktionsudrulning. Involvér dit sikkerhedsteam i gennemgangen — mange punkter kræver både kodegennemgang og live-testning for at verificere korrekt.
For teams, der ønsker uafhængig verificering, tester en professionel MCP sikkerhedsrevision alle 16 tjeklistepunkter mod dit live-miljø ved hjælp af adversarial testteknikker snarere end selvvurdering. Resultatet er en verificeret sikkerhedsstatusrapport med en prioriteret remediationsplan.
OWASP GenAI Security Projects 'MCP Security Minimum Bar' er en gennemgangstjekliste, der definerer de grundlæggende sikkerhedskontroller, der kræves, før en MCP server bør udrulles til produktion. Den dækker fem domæner: Stærk Identitet/Autentificering/Politikhåndhævelse, Streng Isolering og Livscykluskontrol, Betroede og Kontrollerede Værktøjer, Skema-drevet Validering, og Hærdet Udrulning med Løbende Overvågning. Hvis minimumsstandarden ikke opfyldes, betyder det, at MCP serveren ikke bør udrulles, før manglerne er udbedret.
Gennemgå hver kategori systematisk og marker punkter som BESTÅET, IKKE BESTÅET eller IKKE RELEVANT med dokumentation for hver beslutning. Ethvert IKKE BESTÅET i kategori 1 eller 2 (identitet og isolering) bør blokere udrulning — disse er de højest-risiko mangler. IKKE BESTÅET i andre kategorier bør risikoaccepteres med en dokumenteret remediationstidsplan før udrulning. Tjeklisten bør revurderes efter enhver væsentlig ændring af MCP serveren, værktøjsregisteret eller udrulningsmiljøet.
Flere værktøjer understøtter automatiseret MCP sikkerhedsvalidering: Invariant MCP-Scan (specialiseret til MCP sikkerhedsscanning), SAST værktøjer med tilpassede MCP regler, npm audit og pip audit til afhængighedsscanning, OSV-Scanner til sårbarheds-database kontrol, Docker seccomp og AppArmor profiler til runtime-isolering, og SIEM integration til centraliseret overvågning. Intet enkelt værktøj dækker alle tjeklistepunkter — omfattende dækning kræver kombination af statisk analyse, dynamisk testning og løbende overvågning.
Arshia er AI Workflow Engineer hos FlowHunt. Med en baggrund inden for datalogi og en passion for AI, specialiserer han sig i at skabe effektive workflows, der integrerer AI-værktøjer i daglige opgaver og øger produktivitet og kreativitet.
Brug denne tjekliste til selvvurdering, og lad derefter vores team udføre en verificeret sikkerhedsrevision. Vi tester hvert punkt i dit live-miljø og leverer en detaljeret remediationsplan.
MCP servere udsætter en unik angrebsflade, der kombinerer traditionelle API-risici med AI-specifikke trusler. Lær de 6 kritiske sårbarheder identificeret af OWA...
Autentificering er det mest kritiske sikkerhedslag for fjern-MCP-servere. Lær hvorfor OAuth 2.1 med OIDC er obligatorisk, hvordan token-delegering forhindrer Co...
Prompt injection er den primære angrebsvektor mod MCP-servere i produktion. Lær de fire OWASP-anbefalede kontroller: struktureret værktøjsinvokation, Human-in-t...
