API Anahtarı Nedir, İstemci Tarafında Saklamak Neden Risklidir?

---

Bir hava durumu servisinden ya da harita API'sinden aldığınız anahtarı, en hızlı çalışan yol olduğu için doğrudan tarayıcıda çalışan ön uç koduna yapıştırmak cazip gelir. Sayfa çalışır, istek gider, sonuç gelir; sorun görünürde yoktur. Ama o anahtar artık sayfanın kaynak kodunda herkesin görebileceği bir yerde durur.

Bu yazı API anahtarının aslında ne olduğunu, neyi kanıtladığını ve istemci tarafında saklandığında neden risk doğduğunu resmî sağlayıcı belgelerine dayanarak açıklıyor.

API anahtarı kimliğinizi mi, projenizi mi doğruluyor?​

Google Cloud'un kimlik doğrulama belgesine göre standart bir API anahtarı bir "principal" (kullanıcı ya da hizmet hesabı gibi bir kimlik) doğrulamaz; yalnızca isteği faturalama ve kota amacıyla bir projeyle ilişkilendirir. Yani anahtar "bu isteği siz mi yaptınız" sorusuna değil, "bu istek hangi projeye fatura edilecek" sorusuna yanıt veriyor.

Bu ayrım önemli, çünkü bir anahtarın ele geçirilmesi durumunda saldırgan sizin kimliğinizi çalmış olmaz ama sizin projenizin kotasını, faturalandırmasını ve o anahtarın erişebildiği API'leri kullanabilir hale gelir.

"Kısıtlanmamış anahtar" neden güvensiz sayılıyor?​

Aynı belge açık bir uyarı içeriyor: kısıtlanmamış API anahtarlarının güvensiz olduğunu belirtiyor. Google, riski azaltmak için iki tür kısıtlama öneriyor: anahtarın yalnızca belirli API'lerle kullanılabilmesini sağlayan API kısıtlaması ve yalnızca belirli web sitelerinden, IP adreslerinden veya uygulamalardan gelen isteklerde çalışmasını sağlayan uygulama kısıtlaması. Belge her iki kısıtlamanın birlikte ayarlanmasını öneriyor; yalnızca birini eklemek koruma açısından eksik kalıyor.

İstemci tarafına yerleştirilen bir anahtar, tarayıcının "geliştirici araçları" bölümünden ya da sayfa kaynağından herkes tarafından görülebilir; bu yüzden yalnızca referrer/IP kısıtlaması eklemek dahi tam bir çözüm değildir, çünkü anahtar zaten görünür durumdadır. Asıl güvenli desen, hassas anahtarı sunucu tarafında tutup istemciden gelen çağrıyı arka planda kendi sunucunuz devralıp asıl API'ye oradan iletmektir; bu şekilde anahtar hiçbir zaman kullanıcının tarayıcısına ulaşmaz.

Bir anahtarın en sık sızdığı yerler de aslında tahmin edilebilir: genele açık bir kod deposuna anahtarla birlikte commit edilmiş bir yapılandırma dosyası, hata ayıklama sırasında konsola yazdırılıp log dosyasında kalan bir anahtar ya da doğrudan ön uç koduna gömülü bir sabit değer. Üçünde de ortak nokta, anahtarın "yalnızca ben görüyorum" sanılan bir yerde aslında herkese açık hale gelmesi.

Kısıtlama eklemek neden tek başına yetmiyor?​

Google'ın belgesi anahtarı oluşturduktan hemen sonra yapılması gereken iki şeyi ayrı ayrı vurguluyor: anahtar dizesini güvenli bir yerde saklamak ve kısıtlamaları o an eklemek, sonraya bırakmamak. Çünkü bir anahtar kısıtlamasız durumdayken bile kısa süreliğine bir yere yapıştırılmışsa (ör. bir destek talebine, bir ekran görüntüsüne) o kısa pencere sızıntı için yeterli olabilir; kısıtlamayı sonradan eklemek geçmişte sızmış bir kopyayı geçersiz kılmaz, yalnızca gelecekteki kötüye kullanımı sınırlar.

Sızan bir anahtar hangi güvenlik kategorisine girer?​

OWASP'ın API Security projesine göre "Broken Authentication" (API2:2023), kimlik doğrulama mekanizmalarının hatalı uygulanması ve saldırganların kimlik doğrulama jetonlarını (token) ele geçirebilmesiyle ilgili bir risk kategorisi. İstemci tarafında açıkta bırakılan bir API anahtarı da pratikte bu kategoriye giren bir zafiyet örneği; anahtar teknik olarak bir jeton değilse de aynı sonucu doğurur: yetkisiz taraf sizin adınıza istek yapabilir hale gelir.

Aynı proje, API'lerin kendi doğaları gereği uygulama mantığını ve bazen kişisel veri gibi hassas bilgileri dışa açtığını, bu yüzden saldırganlar için giderek daha çekici bir hedef haline geldiğini de belirtiyor. Bir anahtarın sızması, tek başına küçük bir hata gibi görünse de bu geniş yüzeyin bir parçası.

Bir anahtar sızarsa ne yapılır?​

İlk adım anahtarı iptal edip yenisini oluşturmak, ikincisi de nereden sızdığını (genel bir kod deposu, istemci kodu, log dosyası) bulup kapatmak. Bu, genel anlamda bir güvenlik açığı bulunduğunda izlenen sorumlu bildirim mantığıyla örtüşüyor; bu süreci bir güvenlik açığı bulduğunuzda önce kime bildirirsiniz yazımızda ele almıştık.

API'lerle ilk kez çalışıyorsanız bunların web uygulamalarında nasıl bir rol oynadığını genel tanıtım yazımızda, anahtarın gerçek bir entegrasyonda adım adım nasıl devreye girdiğini de hava durumu servisi örneğimizde görebilirsiniz; bu tür örneklerde anahtarın nereye yazıldığına dikkat etmek iyi bir alışkanlık.

Sık Sorulan Sorular​

API anahtarı nedir?
Bir isteği belirli bir projeyle ilişkilendirip faturalama ve kota takibi yapılmasını sağlayan, genelde tek bir kimliği değil projeyi doğrulayan bir tanımlayıcıdır.

API erişim anahtarı nedir, kullanıcı kimliğinden farkı ne?
Kullanıcı girişinden farklı olarak bir "principal" doğrulamaz; yalnızca isteğin hangi projeye ait olduğunu gösterir. Bu yüzden bir anahtarın sızması kimlik hırsızlığından çok proje kotasının ve erişiminin kötüye kullanılması riski taşır.

API anahtarı nasıl alınır?
Kullandığınız servisin (harita, hava durumu, ödeme gibi) geliştirici panelinden bir proje oluşturup o proje için bir anahtar üretilerek alınır; anahtar üretildikten sonra hangi API'lerle ve hangi kaynaklarla kullanılabileceği ayrıca kısıtlanmalıdır.

Özetle​

API anahtarı kimliğinizi değil projenizi doğrular; kısıtlanmamış bırakılması ya da istemci tarafında saklanması, kotanızın ve erişiminizin başkaları tarafından kullanılmasına kapı aralar. Güvenli desen hassas anahtarı sunucu tarafında tutup istemciden gelen isteği oradan yönlendirmek; kısıtlama eklemek ek bir önlemdir ama anahtar zaten görünür durumdaysa tek başına yeterli değildir.

Şu an kullandığınız API anahtarlarından kaçı istemci tarafı kodda açıkta duruyor?

Güncelleme: 25 Ağustos 2026.

---