Bir MCP sunucusunu, kimlik bilgilerinizle hareket eden üçüncü taraf kod olarak değerlendirin ve agent onu çağırabilmeden önce inceleyin. Aşağıdaki kontroller MCP yetkilendirme spesifikasyonuna (2025-06-18 revizyonu) ve MCP güvenlik en iyi uygulamalarına (2025-11-25 revizyonu) dayanır. Revizyonlar birbirinden farklıdır; bu nedenle herhangi bir gereksinime güvenmeden önce güncel spesifikasyonu kontrol edin.
Yetkilendirme isteğe bağlıdır, bu yüzden var olup olmadığını kontrol edin
HTTP transport kullanan sunucular yetkilendirme spesifikasyonunu izlemelidir. STDIO kullanan sunucular ise izlememelidir ve kimlik bilgilerini ortamdan alır. Yerel bir STDIO sunucusu için, istemci yapılandırmanızın sürece aktardığı ortam değişkenlerini listeleyin ve her birinin gerçekten gerekli olup olmadığını sorgulayın.
HTTP sunucusu için kimlik doğrulamasız bir istek gönderin:
curl -i https://mcp.example.com/mcpYanıtta, resource metadata URL'sini veren bir WWW-Authenticate header'ı ile birlikte 401 Unauthorized almanız gerekir. Bu URL'yi çekin ve dokümanın en az bir girişli authorization_servers alanı içerdiğini doğrulayın. Sunucu bunun yerine veri döndürüyorsa incelemeyi orada durdurun.
Ardından spesifikasyonun zorunlu işaretlediği noktaları doğrulayın:
- İstemci her HTTP isteğinde
Authorization: Bearer <access-token>gönderir ve token hiçbir zaman URI sorgu dizesinde yer almaz. - Yetkilendirme sunucusu endpoint'leri HTTPS kullanır; redirect URI'leri localhost ya da HTTPS'tir.
- Yetkilendirme sunucusu, redirect URI'lerini önceden kaydedilmiş değerlerle birebir eşleştirir.
- İstemciler PKCE uygular.
İstemciler ayrıca state parametresini doğrulamalı, yetkilendirme sunucuları da kısa ömürlü access token'lar üretmelidir.
Token audience ve scope
İstemci, hem yetkilendirme hem de token isteklerinde resource parametresini (RFC 8707) göndermelidir; sunucu da her token'ın özellikle kendisi için üretildiğini doğrulamalıdır. Aksi hâlde başka servisler için üretilmiş token'lar bu sunucuya karşı da çalışır.
Token passthrough daha da kötüdür: sunucu kendisi için üretilmemiş bir token'ı kabul eder ve değiştirmeden aşağı akıştaki servislere iletir. Rate limiting ve izleme gibi kontroller token audience'a bağlı olabilir; aşağı akıştaki loglar istekleri yanlış kimliğe atfedebilir ve bu da incelemeyi zorlaştırır.
Audience bağlamasını test etmek için kayıtlı bir istemciyle, yetkilendirme sunucusu metadata'sındaki token_endpoint üzerinden farklı bir kaynak için token isteyin. Bu token'ı MCP sunucusuna karşı yeniden oynatın:
curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp401 bekleyin. Gerekli izinlere sahip olmayan geçerli bir token ise 403 almalıdır. Yetkilendirme sunucusu böyle bir token üretmiyorsa, MCP sunucusunun audience'ı nasıl kontrol ettiğini üreticiye sorun.
Sunucunun token'ları nerede sakladığını da sorun. Public client'larda refresh token'lar rotate edilmelidir; sunucuda önbelleğe alınan ya da loglanan token'lar ise çalınma hedefidir.
Proxy sunucular ve onay (consent)
MCP sunucusu tek bir statik client ID ile üçüncü taraf bir API'nin önünde duruyorsa, en iyi uygulamalardaki confused deputy bölümünü okuyun. Saldırı; statik bir client ID, dinamik client kaydı, üçüncü taraf yetkilendirme sunucusundan gelen bir onay cookie'si ve proxy'de istemci bazında onay bulunmaması koşullarını gerektirir. Sonuncusunu düzeltmek sizin elinizdedir: proxy, kullanıcı başına onaylı client_id değerlerinin bir kaydını tutmalı ve kendi onay sayfasında istemci adını, scope'ları ve redirect URI'yi göstermelidir. Bu sayfa da frame-ancestors veya X-Frame-Options: DENY ile iframe içine alınmayı engellemelidir.
Araçları allowlist'e alın, sonra daraltın
Sunucudan araç listesini isteyin ve görevin gerektirdikleriyle karşılaştırın. Fazla olan her şey, OWASP LLM06:2025 terimleriyle aşırı işlevsellik (excessive functionality) demektir. Bunu kaldırın ya da agent'ın çağırmasını engelleyin.
Listeyi baseline olarak kaydedin ve her sunucu güncellemesinden sonra diff alın; böylece bir güncellemeyle eklenen araç, agent onu çağırabilmeden önce incelenir. Ardından geriye kalan her aracı kontrol edin:
- Araç "shell komutu çalıştır" ya da "URL getir" gibi açık uçlu mu? Dar kapsamlı bir araçla değiştirin. OWASP'ın örneği, shell erişimi yerine dosya yazan bir araçtır.
- Aşağı akışta hangi kimliği kullanıyor? Veri okuyan bir araç
UPDATE,INSERTveDELETEile değil, yalnızcaSELECTile bağlanmalıdır. - Tek bir kullanıcı adına mı işlem yapıyor? O zaman genel amaçlı ayrıcalıklı bir hesapla değil, minimum scope ile OAuth üzerinden kimlik doğrulamalıdır.
Sınırları aşağı akıştaki sistemde uygulayın. OWASP buna complete mediation der: bir eylemin izinli olup olmadığına modelin karar vermesine güvenmeyin.
Yazma eylemleri için insan onayı
Halüsinasyon ve prompt injection, zarar verici eylemlerin yaygın tetikleyicileridir; bu yüzden yüksek etkili eylemlerde döngüde bir insan bulunmalıdır. OWASP, gelen iletileri özetleyen bir e-posta asistanını anlatır. Enjekte edilmiş bir e-posta, asistanı gelen kutusunda hassas bilgi aramaya ve bunları saldırgana iletmeye kandırır.
Salt okunur bir extension, salt okunur bir OAuth scope'u ya da gönderimden önce taslak her e-postanın manuel incelenmesi, bu saldırıyı tek başına engelleyebilirdi. Mümkün olan yerlerde bunları katmanlı uygulayın.
Silen, gönderen ya da paylaşan her şey onay listesinde yer almalıdır. Onayı extension'a ya da aşağı akıştaki sisteme yerleştirin. Loglama ve rate limiting aşırı özerkliği engellemez, ancak istenmeyen eylemlerin fark edilmesini kolaylaştırır.
İstemci sunucu tarafında çalışıyorsa
OAuth discovery sırasında istemci, resource_metadata, authorization_servers ve token_endpoint dahil olmak üzere sunucunun verdiği URL'leri çeker. Kötü niyetli bir sunucu bunları iç adreslere ya da 169.254.169.254 adresindeki cloud metadata endpoint'ine yönlendirebilir.
Production'da HTTPS zorunlu kılın, özel ve ayrılmış aralıkları engelleyin, yönlendirme hedeflerini doğrulayın ya da otomatik yönlendirmeleri kapatın. IP doğrulamasını elle yazmayın; çünkü octal, hex ve IPv4-mapped IPv6 hileleri özel parser'ları atlatır. Smokescreen gibi bir egress proxy kullanmayı değerlendirin.
Sonra test edin. WWW-Authenticate header'ında http://169.254.169.254/ adresini gösteren bir resource_metadata URL'si taşıyan 401 döndüren düşmanca bir test sunucusu ayağa kaldırın; ardından aynı testi iç bir adrese yönlendiren bir URL ile tekrarlayın. İstemci ikisini de reddetmeli ve iç hedefteki bir listener hiçbir istek görmemelidir.
Nereden başlamalı
- Agent'larınızın kullandığı her MCP sunucusunu transport'u ve operatörüyle birlikte listeleyin. Hesabını veremediğiniz her sunucuyu kaldırın.
- Her HTTP sunucusuna
curl -içalıştırın veWWW-Authenticateheader'lı401yanıtını doğrulayın. Ardından başka bir kaynak için üretilmiş bir token'ı yeniden oynatın. - Statik client ID kullanan proxy sunucularda onay akışını gözden geçirin: istemci bazında kayıt, onay sayfası içeriği, framing koruması.
- Her sunucunun araç listesini baseline olarak kaydedin, görevin gerektirdiği kadarına indirin, her araca en az ayrıcalıklı kimliği verin ve yazma ile silme araçları için insan onayı zorunlu kılın.
- Sunucu tarafında çalışan istemciler için düşmanca test sunucusuyla SSRF testini çalıştırın.
- Bir sunucu güncellendiğinde, araç eklediğinde ya da scope'larını değiştirdiğinde 2. ile 5. adımları tekrarlayın.
Dışarıdan bir inceleme için danışmanlık hizmetimize göz atın. Sızma testi hizmetimiz, token ve onay kontrollerini sizin ortamınıza karşı çalıştırabilir.
