MCP Sunucusu Güvenlik İncelemesi
Yetkiden Tool Çağrısına

İlk Soru: Sunucu Hangi Yetkiyle Çalışıyor?

MCP güvenlik incelemesinin başlangıç noktası tool açıklaması değil process yetkisidir. Yerel sunucu istemciyle aynı kullanıcı hesabının dosya ve ağ haklarını taşıyorsa, tek bir tool beklenenden çok daha geniş etki alanına sahip olabilir. Uzak sunucuda ise erişim token’ının hangi kaynağa ve hangi kullanıcıya bağlı olduğu kritik hale gelir.

Envanterde her tool için çağrılabilen sistem, gerekli scope, veri sınıfı, yazma etkisi, geri alınabilirlik ve insan onayı belirtilmelidir. “Read” adı taşıyan bir tool bile query parametresi üzerinden geniş veri çıkarabiliyorsa düşük riskli değildir.

Token Var Diye Yetkili Saymayın

Resmî MCP Authorization spesifikasyonu HTTP tabanlı akışlarda OAuth 2.1 yaklaşımını, protected-resource metadata’yı ve token audience doğrulamasını temel alır. Sunucu yalnızca imzayı değil, token’ın özellikle kendisi için üretildiğini de doğrulamalıdır. Token passthrough, bir kaynağa verilen kimlik bilgisinin başka kaynakta kullanılmasına yol açar ve açıkça kaçınılması gereken bir tasarımdır.

Her istek Authorization header’ı taşımalı; token URI query string’e konmamalı; geçersiz/expired token 401, yetersiz scope 403 üretmelidir. Public client akışlarında PKCE, redirect URI doğrulaması ve kısa ömürlü token kullanımı temel kontrollerdir.

Confused Deputy ve Üçüncü Taraf Yetkisi

MCP proxy bir üçüncü taraf API’ye ortak client kimliğiyle bağlanırken farklı MCP client’larını dinamik kaydediyorsa, izin akışındaki bağlam kaybolabilir. Kullanıcı daha önce üçüncü tarafa izin verdiği için consent cookie tekrar onay istemez; kötü niyetli client bu oturumu kendi akışına taşıyabilir.

Çözüm, her dinamik client için açık kullanıcı onayı ve authorization kodunun hangi MCP client’a ait olduğunun doğrulanmasıdır. Üçüncü taraf token doğrudan MCP client’a aktarılmaz; sunucu kendi kaynağına bağlı ayrı yetki üretir.

Session Kimlik Değildir; Sandbox Varsayılan Olmalıdır

Session ID authentication yerine kullanılmamalıdır. Tahmin edilemez üretilmeli, kullanıcı kimliğine bağlanmalı ve gerekli olduğunda döndürülmelidir. Uzak HTTP transport’unda her istek yetkilendirilirken yerel süreçte stdio, saldırı yüzeyini yalnızca istemci process’e sınırlar.

Yerel MCP sunucuları minimum dosya sistemi ve ağ erişimiyle sandbox içinde çalıştırılmalıdır. Genişletilmiş erişim varsayılan değil, kullanıcı tarafından belirli dizin veya hedef için açıkça verilmiş istisna olmalıdır.

Tool Açıklamasını Güven Sınırı Kabul Etmeyin

Tool açıklaması kullanıcı arayüzünü ve model seçimini etkiler; fakat davranışın güvenilir kanıtı değildir. Sunucu güncellemesi açıklamayı değiştirmeden daha geniş iş yapabilir. Client, hassas eylemlerde parametreleri görünür kılmalı ve çağrı öncesi kullanıcı onayı almalıdır.

Sunucu tarafında input schema yalnızca tip kontrolü yapmamalı; path traversal, SSRF, aşırı sorgu, beklenmeyen enum ve çapraz tenant erişimi gibi iş kurallarını da doğrulamalıdır. Output ise modele dönmeden önce veri sınıfı ve boyut sınırlarından geçmelidir.

On İki Maddelik MCP İnceleme Listesi

1. Tool başına en az yetki ve ayrı scope.
2. Token signature, issuer, expiry ve audience doğrulaması.
3. Token passthrough yasağı.
4. PKCE ve kesin redirect URI kontrolü.
5. Client başına açık consent.
6. Session’ın kullanıcıya bağlanması; auth yerine kullanılmaması.
7. Yerel sunucuda stdio veya kısıtlı IPC.
8. Dosya sistemi ve ağ sandbox’ı.
9. Schema yanında iş kuralı doğrulaması.
10. Geri döndürülemez eylemde insan onayı.
11. Token, secret ve Authorization header loglamama.
12. Tool sürümü ve davranış değişikliği için regresyon testi.

Kaynaklar ve Kanıt Sınırı

• MCP Security Best Practices
• MCP Authorization Specification — 2025-11-25
• OWASP Top 10 for Agentic Applications 2026

Bu yazı Enes Deniz tarafından hazırlanmış bağımsız bir teknik değerlendirmedir. Bağlantılı upstream proje veya standart kuruluşu tarafından yayımlanmış ya da onaylanmış bir metin değildir. Merge, test ve kapsam iddiaları yukarıdaki birincil kayıtlara bağlanmıştır.