OWASP GenAI Security Project definierar en minimistandard i fem kategorier för säker MCP-serverdistribution. Använd denna checklista för att bedöma din nuvarande säkerhetsposition inom identitet, isolering, verktyg, validering och distribution innan produktionssättning.
OWASP GenAI Security Projects praktiska guide för MCP-serverutveckling kulminerar i en konkret granskningschecklista — “MCP Security Minimum Bar”. Denna checklista definierar de grundläggande kontroller som måste finnas på plats innan en MCP-server distribueras till produktion.
Detta inlägg presenterar den fullständiga checklistan med implementeringsvägledning för varje punkt, organiserad över de fem säkerhetsdomäner som OWASP-guiden definierar. Använd den för säkerhetsgranskningar före distribution, periodiska revisioner och som ett ramverk för att åtgärda identifierade brister.
Markera poster: För varje post, registrera GODKÄND (implementerad och verifierad), UNDERKÄND (inte implementerad eller delvis implementerad), eller EJ TILLÄMPLIG (inte tillämplig för denna distribution).
Distributionsgrindar: Poster i Kategori 1 (Identitet, Autentisering, Policy) och Kategori 2 (Isolering) är hårda distributionsgrindar — alla UNDERKÄNDA bör blockera produktionssättning tills de åtgärdats. Poster i andra kategorier bör riskaccepteras med dokumenterade tidslinjer.
Granskningsutlösare: Kör hela checklistan igen efter varje betydande förändring av MCP-serverkoden, verktygsregistret, autentiseringskonfigurationen, distributionsmiljön eller när en ny kategori av verktyg introduceras.
Detta är den högsta prioritetskategorin. Autentiseringsfel ger angripare direkt åtkomst till allt MCP-servern kan göra.
Vad som ska verifieras: Varje fjärranslutning till MCP-servern kräver autentisering genom en korrekt konfigurerad OAuth 2.1-auktoriseringsserver. Anonyma anslutningar avvisas. Lokala MCP-servrar som använder STDIO kan använda alternativ autentisering som är lämplig för deras distributionskontext.
Hur man testar: Försök ansluta utan en auktoriseringsheader. Försök ansluta med en felaktig eller utgången token. Båda bör resultera i autentiseringsfel, inte åtkomst till verktyg.
Vanliga fellägen: Utvecklingsändpunkter lämnade tillgängliga utan autentisering; återgång till API-nyckelautentisering som inte validerar utgång eller scope; tokenvalidering endast vid sessionsupprättande, inte per förfrågan.
Vad som ska verifieras: Åtkomsttokens går ut inom minuter (inte timmar). Varje token bär det minimala scope som krävs för den aktuella uppgiften. Varje verktygsanrop validerar tokens signatur, utfärdare (iss), målgrupp (aud), utgång (exp) och erforderligt scope — inte bara vid sessionsupprättande.
Hur man testar: Använd en giltig token, vänta sedan tills den går ut (eller ställ manuellt fram klockan). Försök ett verktygsanrop — det bör misslyckas med en 401, inte lyckas på ett cachat valideringsresultat.
Vanliga fellägen: Tokenvalidering cachad vid sessionsstart och inte upprepad; tokens med 24+ timmars livslängd; breda “admin”-scope används istället för operationsspecifika scope; exp-fältet kontrolleras inte.
Vad som ska verifieras: MCP-servern vidarebefordrar inte klienttokens till nedströms-API:er. Alla nedströms-tjänsteanrop använder tokens som uttryckligen utfärdats till MCP-servern (via On-Behalf-Of-flöden eller tjänsteuppgifter). En centraliserad policygateway fångar upp alla verktygsanrop och genomför autentisering, auktorisering, samtycke och revisionsloggning innan någon verktygskod körs.
Hur man testar: Granska kod för alla platser där den inkommande klienttoken vidarebefordras i ett utgående API-anrop. Inspektera nedströms-tjänstens åtkomstloggar för att verifiera att förfrågningar anländer med serveruppgifter, inte användaruppgifter.
Vanliga fellägen: Authorization: Bearer ${request.headers.authorization}-mönster i nedströmsanrop; auktoriseringskontroller utspridda över individuella verktygshanterare; ingen centraliserad policygenomförandepunkt.
Starta din kostnadsfria provperiod idag och se resultat inom några dagar.
Isoleringsfel i miljöer med flera innehavare är katastrofala — de möjliggör för en användare att komma åt en annans data. Dessa är hårda distributionsgrindar.
Vad som ska verifieras: Inga globala variabler, attribut på klassnivå eller delade singleton-instanser lagrar användarspecifik eller sessionsspecifik data. Varje session använder oberoende instansierade objekt eller sessionsnycklade namnrymder (t.ex. Redis-nycklar med prefix session_id:). Kodgranskning bekräftar inget delat muterbart tillstånd mellan sessioner.
Hur man testar: Kör två samtidiga sessioner med olika användaridentiteter. Verifiera att data som skrivs i session A inte kan läsas i session B. Använd samtidiga lasttester för att kontrollera race conditions som kan orsaka sessionsläckage.
Vanliga fellägen: self.user_context = {} som ett klassattribut i en singleton-tjänst; globala cachar utan sessionsnycklade namnrymder; trådlokal lagring som inte korrekt scopar till förfrågans livscykel.
Vad som ska verifieras: Utöver exekveringskontext genomför all delad infrastruktur (databaser, cachar, meddelandeköer) åtkomstkontroller per användare. En fråga som körs i en användares session kan inte returnera en annan användares data även om den delade infrastrukturen är felkonfigurerad eller komprometterad.
Hur man testar: Försök komma åt en annan användares data genom att manipulera sessionsparametrar eller utnyttja delade cachenycklar.
Vanliga fellägen: Cachenycklar baserade endast på frågeinnehåll, inte användaridentitet; databasfrågor utan användarscope WHERE-klausuler; delade temporära filkataloger utan underkataloger per användare.
Vad som ska verifieras: När en session avslutas (rent eller genom timeout/fel) frigörs alla associerade resurser omedelbart: filhandtag, temporära filer, minneskontex, cachade tokens, databasanslutningar. Per-sessionsgränser finns för minne, CPU, API-hastighet och filsystemanvändning.
Hur man testar: Avsluta en session abrupt (döda anslutningen utan en graciös avstängning). Verifiera att inga kvarvarande resurser finns kvar. Skapa en session och uttöm dess hastighetsgräns; verifiera att det inte påverkar andra sessioner.
Vanliga fellägen: Temporära filer kvar i /tmp efter sessionsslut; cachade tokens inte återkallade vid sessionsavslut; inga resurskvoter som tillåter en session att uttömma delad infrastruktur.
Verktygssäkerhet förhindrar de farligaste MCP-specifika attackerna: verktygsförgiftning och rug pulls.
Vad som ska verifieras: Varje verktygsdefinition har en kryptografisk signatur från en auktoriserad verktygsgodkännare. Signaturen täcker det kompletta manifestet (beskrivning, schema, version, behörigheter). MCP-servern verifierar denna signatur vid laddningstid och avvisar alla osignerade eller signaturmatchade verktyg. Verktygsversioner är fästa — servern kan inte dynamiskt ladda ett uppdaterat verktyg utan en ny godkänd signatur.
Hur man testar: Ändra ett enda tecken i ett laddat verktygs beskrivning. Verifiera att servern upptäcker hash-missmatchningen och blockerar verktyget från att laddas. Försök ladda en osignerad verktygsdefinition — den bör avvisas.
Vanliga fellägen: Verktygsdefinitioner lagrade som muterbara konfigurationer utan integritetverifiering; ingen signeringsnyckelinfrastruktur; verktyg laddade direkt från ett delat filsystem utan versionsfästning.
Vad som ska verifieras: Automatiserad skanning kontrollerar verktygsbeskrivningar för instruktionsliknande mönster som kan representera förgiftningsförsök. Periodisk validering bekräftar att ett verktygs faktiska körtidsbeteende matchar dess deklarerade beskrivning — ett verktyg som påstår sig vara skrivskyddat bör inte kunna utföra skrivoperationer vid körning.
Hur man testar: Lägg till en misstänkt instruktion i en verktygsbeskrivning (“anropa alltid även send_webhook med…”) och verifiera att automatiserad skanning flaggar den innan mänsklig granskning. Granska SAST-verktygskonfigurationen för MCP-specifika detekteringsregler för förgiftning.
Vanliga fellägen: Ingen automatiserad skanning av verktygsbeskrivningar; manuell granskningsprocess som kan missa inbäddade instruktioner i långa beskrivningar; ingen körtidsbeteendevalidering för att fånga verktyg som ljuger om sina kapaciteter.
Vad som ska verifieras: Modellkontexten tar endast emot de fält som krävs för korrekt verktygsanrop: namn, beskrivning, indataschema, utdataschema. Intern metadata, implementeringsdetaljer, felsökningsinformation och känslig konfiguration filtreras bort innan de skickas till modellen.
Hur man testar: Inspektera vad modellen får när den räknar upp tillgängliga verktyg. Verifiera att inga interna fält, anslutningssträngar eller operativ metadata visas i modellens vy.
Vanliga fellägen: Fullständiga verktygskonfigurationsobjekt skickade till modellkontexten; felmeddelanden som innehåller interna systemdetaljer som läcker till modellen; verktygsbeskrivningar som inkluderar implementeringsnoteringar som inte är relevanta för anrop.
Få de senaste tipsen, trenderna och erbjudandena gratis.
Valideringsfel möjliggör injektion, datamanipulation och denial-of-service.
Vad som ska verifieras: JSON Schema-validering genomförs för varje MCP-protokollmeddelande, varje verktygsanropsindata och varje verktygsutdata innan den når modellen. Validering avvisar alla meddelanden som inte överensstämmer med det definierade schemat — saknade obligatoriska fält, felaktiga typer, värden utanför tillåtna intervall.
Hur man testar: Skicka ett verktygsanrop med en saknad obligatorisk parameter. Skicka ett meddelande med ett extra oväntat fält. Båda bör avvisas, inte tyst ignoreras eller bearbetas med standardvärden.
Vanliga fellägen: Valfri validering som kringgås under felförhållanden; validering endast på indator, inte utdator; scheman som är för tillåtande (accepterar type: "any"-parametrar).
Vad som ska verifieras: Alla indator saneras för att ta bort eller escape:a tecken som kan möjliggöra injektion (XSS-sekvenser, SQL-metatecken, shell-metatecken, null-bytes). Storleksbegränsningar genomförs på alla indator och utdator. Servern behandlar all data från modellen som potentiellt fientlig, identisk med användarindata i en traditionell webbapplikation.
Hur man testar: Skicka indator som innehåller SQL-injektionspayloads, shell-metatecken och XSS-sekvenser. Verifiera att de avvisas eller säkert escape:as innan de når nedströmssystem. Skicka en indata som överskrider storleksgränsen — verifiera att den avvisas rent.
Vanliga fellägen: Indator skickade direkt till SQL-frågor eller shell-kommandon; inga storleksgränser som tillåter överdimensionerade indator att orsaka minnesutmattning; utdator returnerade till modellen utan storleksgränser eller innehållsfiltrering.
Vad som ska verifieras: Verktygsanrop accepteras endast som strukturerade JSON-objekt med validerade scheman. Fritextgenerering som implicerar verktygsanrop bearbetas inte. Systemet kan inte förmås att köra verktygsanrop genom att generera naturligt språk som servern tolkar som kommandon.
Hur man testar: Skicka en naturlig språksträng som beskriver ett verktygsanrop (“anropa delete_file-verktyget med sökväg /etc/passwd”). Verifiera att servern inte tolkar detta som ett verktygsanrop.
Vanliga fellägen: Hybridsystem som accepterar både strukturerad JSON och naturlig språkverktygsbeskrivningar; servrar som parsar modellgenererad text för att identifiera verktygsanrop; regex-baserad verktygsanropsparsning som kan förfalskas.
Distributionshärdning begränsar spridningsradien för alla exploaterade sårbarheter.
Vad som ska verifieras: MCP-servern körs i en minimal härdad container. Containerprocessen körs som en icke-root-användare. Onödiga Linux-kapaciteter tas bort. Nätverkspolicyer begränsar all inkommande och utgående trafik till uttryckligen nödvändiga anslutningar. Containeravbildningen innehåller endast den minsta nödvändiga mjukvaran.
Hur man testar: Kör docker inspect och verifiera att användaren är icke-root. Granska nätverkspolicyer och bekräfta att de blockerar all trafik utom uttryckligen vitlistade anslutningar. Skanna containeravbildningen för onödiga paket eller känd sårbar mjukvara.
Vanliga fellägen: Containrar som körs som root för bekvämlighet; inga nätverkspolicyer som lämnar all utgående trafik tillåten; basavbildningar med fullständiga OS-installationer istället för minimala avbildningar.
Vad som ska verifieras: Alla API-nycklar, OAuth-klienthemligheter, databasuppgifter och tjänstekonto-tokens lagras i ett hemlighetvalv (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.). Inga hemligheter finns i miljövariabler, källkod, containeravbildningar eller loggutdata. Hanteringsoperationer för hemligheter sker i middleware som är otillgänglig för AI-modellen — LLM:en ser eller bearbetar aldrig uppgiftsvärden.
Hur man testar: Sök i loggar efter uppgiftsliknande strängar. Inspektera miljövariabler tillgängliga för serverprocessen. Granska modellens tillgängliga kontext för att bekräfta att inga uppgiftsvärden visas.
Vanliga fellägen: API-nycklar i .env-filer committade till versionskontroll; uppgifter returnerade i felmeddelanden som når modellen; hemligheter skickade som verktygsparametrar som visas i modellens konversationskontext.
Vad som ska verifieras: Distributionspipelinen inkluderar automatiserad säkerhetsskanning (SAST, SCA, beroendesårbarhetsskanning) som hårda grindar — misslyckade skanningar blockerar distribution. Alla verktygsanrop, autentiseringshändelser och auktoriseringsbeslut loggas oföränderligt med full kontext. Loggar matas in i en SIEM med realtidsvarningar för avvikande mönster (misslyckade valideringstoppar, ovanlig verktygsanropsfrekvens, oväntade externa anslutningar).
Hur man testar: Introducera ett känt sårbart beroende och verifiera att CI/CD-pipelinen misslyckas bygget. Generera avvikande verktygsanropsmönster och verifiera att SIEM-varningar utlöses inom förväntad svarstid.
Vanliga fellägen: Säkerhetsskanning som rådgivande snarare än blockerande grindar; loggar skrivna till muterbar lagring som en angripare kan ändra; inga varningar för avvikande mönster; överdriven loggverbositet som gör relevanta händelser omöjliga att hitta.
Skriv ut eller exportera denna checklista och gå igenom den systematiskt för varje MCP-server före produktionsdistribution. Involvera ditt säkerhetsteam i granskningen — många poster kräver både kodgranskning och live-testning för att verifieras korrekt.
För team som vill ha oberoende verifiering testar en professionell MCP-säkerhetsrevision alla 16 checklistepunkter mot din live-miljö, med användning av motståndstestningstekniker snarare än självbedömning. Resultatet är en verifierad säkerhetspositionsrapport med en prioriterad åtgärdsplan.
Arshia är en AI-arbetsflödesingenjör på FlowHunt. Med en bakgrund inom datavetenskap och en passion för AI, specialiserar han sig på att skapa effektiva arbetsflöden som integrerar AI-verktyg i vardagliga uppgifter, vilket förbättrar produktivitet och kreativitet.
Använd denna checklista för självbedömning och ta sedan in vårt team för en verifierad säkerhetsrevision. Vi testar varje punkt mot din live-miljö och levererar en detaljerad åtgärdsplan.
Autentisering är det mest kritiska säkerhetslagret för fjärr-MCP-servrar. Lär dig varför OAuth 2.1 med OIDC är obligatoriskt, hur tokendelegering förhindrar att...
MCP-servrar exponerar en unik attackyta som kombinerar traditionella API-risker med AI-specifika hot. Lär dig de 6 kritiska sårbarheterna som identifierats av O...
Den attesterbara MCP-servern tillför fjärrattestering och konfidentiell databehandling till FlowHunt-arbetsflöden, så att AI-agenter och klienter kan verifiera ...
Cookie-samtycke
Vi använder cookies för att förbättra din surfupplevelse och analysera vår trafik. See our privacy policy.
