API Güvenliği Nasıl Sağlanır? Kimlik Doğrulama, Yetkilendirme, Token Ömrü, Hız Sınırı ve İzleme Rehberi

Bir bayi portalınız, bir mobil uygulamanız ve üç pazaryeri bağlantınız var. Hepsi aynı kapıdan, yani API'den (uygulama programlama arayüzü) içeri girip veriye ulaşıyor. Kapı bir kez yanlış kurulduğunda sorun bir ekranda değil, bütün sistemde ortaya çıkar: başkasının siparişi görünür, sızan bir anahtar aylarca fark edilmez, bir saldırgan şifre denemelerini saatlerce sürdürür. API güvenliği, bu kapıyı kimin, neye, ne kadar süreyle ve hangi sınırlarla açabileceğini baştan tasarlama işidir.

Bu rehberde API güvenliğinin ne olduğunu, kimlik doğrulama ile yetkilendirme farkını, token ömrünün riski nasıl daralttığını, hız sınırının kaba kuvvet denemesini nasıl yavaşlattığını, girdi doğrulamayı, webhook imzalarını, günlük kaydı ve izlemeyi, uç nokta risk puanlamasını ve yayın öncesi kontrol listesini anlatıyoruz. Örnek rakamlar temsilîdir; gerçek bir sistemin ölçümü ya da sektör ortalaması değildir.

API Güvenliği Nedir ve Neden Ayrı Ele Alınır?

API güvenliği, uygulamaların birbiriyle ve istemcilerle veri alışverişini yaptığı arayüzü yetkisiz erişime, veri sızıntısına ve kötüye kullanıma karşı korumaktır. Web sayfası güvenliğinden ayrı ele alınır, çünkü API'ler doğrudan veriyi döndürür: ekran tasarımı onları saklamaz, saldırgan tarayıcıyı atlayıp isteği kendisi gönderebilir.

API'nin ne olduğunu ve entegrasyonların nasıl kurulduğunu API entegrasyonu nedir rehberimizde anlattık. Burada konu, kurulmuş ya da kurulacak bir API'nin nasıl sağlam tutulacağıdır. Güvenlik sorunlarının büyük kısmı karmaşık saldırılardan değil, eksik yetki denetimi, fazla veri döndüren yanıtlar ve sızmış anahtarlar gibi sıradan hatalardan çıkar; OWASP'ın API güvenliği listesi de bu tür yaygın zayıflıkları derler ve kontrol listesi olarak kullanılabilir.

Okumanızı öneririz: Entegrasyon hizmetimiz: pazaryeri, e-Fatura ve kargo

Kimlik Doğrulama ile Yetkilendirme Arasındaki Fark Nedir?

İkisi sık karıştırılır. Kimlik doğrulama (authentication) "bu istek kimden geliyor?" sorusunu, yetkilendirme (authorization) "bu kişi bu işi yapabilir mi?" sorusunu yanıtlar. Kimliği doğrulanmış her kullanıcı her veriyi görebiliyorsa sistem güvensizdir; en sık görülen API açığı da budur.

Yöntem seçimi riskle orantılı olmalıdır: dahili bir rapor ucu için API anahtarı yeterli olabilir, müşteri verisi döndüren bir uç için kısa ömürlü token ve kapsam denetimi gerekir. Hiçbir yöntem tek başına yetki sorununu çözmez; yetki kuralları ayrıca yazılır.

Güvenli Bir API İsteği Hangi Katmanlardan Geçer?

Her isteği aynı sıralı kapılardan geçirmek, güvenliği tek bir kişinin dikkatine bağlı olmaktan çıkarır. Sıra önemlidir: önce trafik şifrelenir, sonra kimlik doğrulanır, sonra yetki denetlenir, girdi şemaya uydurulur, hız ve boyut sınırlanır ve sonuç kayda yazılır.

Bu kapıları her uç noktada yeniden yazmak yerine ortak bir katmanda, örneğin bir API ağ geçidinde (gateway) toplamak hem hatayı hem bakım yükünü azaltır. Yeni bir uç nokta eklendiğinde güvenlik katmanları kendiliğinden devreye girer; unutulan bir kapı kalmaz.

Yetkilendirme Nasıl Doğru Kurulur?

Yetkilendirme iki düzeyde yapılır. Rol ve kapsam düzeyinde "bu kullanıcı siparişleri okuyabilir mi?" sorusu sorulur. Nesne düzeyinde ise "bu sipariş bu kullanıcıya mı ait?" sorusu sorulur. İkincisi unutulduğunda kullanıcı, adres çubuğundaki sipariş numarasını değiştirerek başkasının siparişini görebilir; bu, API açıklarının en yaygın biçimidir.

• Varsayılan olarak reddedin: Açıkça izin verilmeyen her işlem reddedilir.
• Nesne sahipliğini her istekte kontrol edin: Kimlik numarasını istemciden gelen değere değil, token'daki kimliğe göre sorgulayın.
• Kapsamları dar tutun: "Siparişleri oku" ve "sipariş oluştur" ayrı kapsamlardır; bir rapor aracına yazma yetkisi verilmez.
• Yönetici uçlarını ayırın: Yönetim işlemleri ayrı yol, ayrı rol ve ek doğrulama ile korunur.
• Yanıtı sınırlayın: Veritabanındaki nesnenin tamamını değil, istemcinin ihtiyaç duyduğu alanları döndürün.

Rol ve yetki tasarımını gereksinim aşamasında yazmak, sonradan eklemekten çok daha ucuzdur; yaklaşımı yazılım gereksinim analizi rehberimizde ele aldık.

Token Ömrü Riski Nasıl Daraltır?

Çalınan bir token, süresi dolana kadar çalan kişiye kimlik gibi hizmet eder. Bu yüzden erişim token'ının ömrü kısa tutulur; uzun süreli oturum için ayrı bir yenileme belirteci kullanılır ve o belirteç yalnız güvenli yerde saklanır.

Örnek (temsilî): 24 saat ömürlü bir token sızdığında saldırgan bir gün boyunca yetkili görünür. 15 dakikalık token ile aynı sızıntı en çok çeyrek saat işe yarar ve yenileme belirteci iptal edildiğinde yeni token alınamaz. Kısa ömrün bedeli, istemcinin token'ı daha sık yenilemesidir; bu otomatik yapılır, kullanıcı fark etmez.

Anahtarlar düzenli aralıklarla döndürülmeli, çalışan ayrıldığında ya da şüphe doğduğunda hemen iptal edilmelidir. Kaynak kod deposuna yanlışlıkla yazılan bir anahtar, silinse bile geçmişte kaldığı için sızmış sayılır ve değiştirilir.

Hız Sınırı Kaba Kuvvet Denemesini Nasıl Yavaşlatır?

Hız sınırı (rate limiting), bir istemcinin belirli sürede gönderebileceği istek sayısını sınırlar. Parola ya da doğrulama kodu tahmini gibi denemeye dayalı saldırıları pahalı hale getirir, ayrıca hatalı çalışan bir istemcinin sunucuyu boğmasını engeller.

Örnek (temsilî): 6 haneli rakamsal doğrulama kodunda 10⁶ = 1.000.000 olası değer vardır. Saniyede 1.000 istek atılabiliyorsa tüm kombinasyonlar 1.000.000 ÷ 1.000 = 1.000 saniyede, yani yaklaşık 16,7 dakikada denenir. Aynı uç dakikada 100 istekle sınırlandığında süre 1.000.000 ÷ 100 = 10.000 dakikaya, yani yaklaşık 6,9 güne çıkar. Hesap başına 5 hatalı denemeden sonra kilit ve uyarı eklenirse deneme sayısı 5 ile biter.

• Anahtar başına ve adres başına sınır koyun: Yalnız adrese göre sınır, dağıtık saldırıda yetmez.
• Hassas uçları daha sıkı sınırlayın: Giriş, parola sıfırlama ve kod doğrulama uçlarında limit düşük olmalıdır.
• 429 yanıtıyla bilgi verin: İstemciye ne zaman yeniden deneyeceğini bildirin; meşru istemci bekleyebilsin.
• İstek boyutunu da sınırlayın: Çok büyük gövdeli istekler belleği tüketebilir.

Girdi Doğrulama ve Çıktı Sınırlama Neden Gereklidir?

İstemciden gelen her değer güvenilmezdir. Alan türü, uzunluğu, biçimi ve izin verilen değer aralığı bir şemayla tanımlanır; şemaya uymayan istek işlenmeden reddedilir. Bu, veritabanı sorgusuna sızdırılmaya çalışılan kötü niyetli girdiyi de en baştan eler.

• Sorguları parametreyle çalıştırın: Kullanıcı girdisini sorgu metnine doğrudan eklemeyin.
• Beklenmeyen alanları reddedin: İstemci "yetki" ya da "tutar" gibi alanları kendisi gönderip değiştirememeli.
• Hata mesajlarını sade tutun: Yığın izi ve veritabanı adı gibi ayrıntılar dışarıya verilmez, yalnız günlüğe yazılır.
• Dosya yüklemeyi sınırlayın: Tür, boyut ve içerik denetlenir, dosya çalıştırılabilir alanda saklanmaz.

Çıktı tarafında da aynı özen gerekir. Bir ürün listesi ucu, maliyet ve tedarikçi gibi dahili alanları da döndürüyorsa bayi o alanları görebilir. Yanıt alanlarını rol bazında tanımlamak ve test etmek, bu tür sızıntıyı önler; test yaklaşımını yazılım testi rehberimizde anlattık.

Webhook ve Dış Bağlantılar Nasıl Güvenceye Alınır?

Webhook'ta rol tersine döner: sizin API'nize dış bir sistem istek gönderir. İsteğin gerçekten beklenen kaynaktan geldiğini doğrulamazsanız herkes sahte sipariş ya da ödeme bildirimi gönderebilir.

Dış sistemlerle çalışırken ilk deneme başarısı ve yinelenen kayıt sorunları da güvenlikle iç içedir; aynı olayı iki kez işlemeyi önleyen yaklaşımı e-Fatura entegrasyonu rehberimizde çift fatura engeli başlığında anlattık.

Günlük Kaydı ve İzleme Saldırıyı Nasıl Erken Yakalar?

Kaydı olmayan saldırı fark edilmez. Her istek için zaman, kimlik, uç nokta, sonuç kodu ve istemci adresi kaydedilmeli; parola, token ve kişisel verinin kendisi ise kayda yazılmamalıdır. Kayıtlar, sıradan davranışı bilirseniz anormali yakalamak için kullanılır.

Örnek (temsilî): bir API günde ortalama 20.000 istek alıyor ve normalde bunların yaklaşık %1'i yetkisiz (401) sonuç dönüyor. Bir gün 1.200 istek yetkisiz dönerse oran 1.200 ÷ 20.000 = %6'dır; normalin altı katıdır. Bu, kaba kuvvet denemesi ya da sızmış bir istemci olabilir; eşik aşıldığında otomatik uyarı gitmesi gerekir.

• Ölçülecek göstergeler: Yetkisiz yanıt oranı, hız sınırına takılan istek sayısı, uç nokta başına hata oranı, olağandışı saatlerdeki trafik.
• Uyarı eşikleri: Normal oranın birkaç katı olarak tanımlanır; eşik zamanla gerçek verilerle ayarlanır.
• Kayıtları korumak: Yazma yetkisi sınırlı tutulur, kayıtlar değiştirilemez biçimde saklanır.
• Saklama süresi: Kişisel veri içeren kayıtların süresi ilgili mevzuata göre belirlenir; ayrıntı için hukuk danışmanına başvurun.

Okumanızı öneririz: İş zekâsı (BI) nedir? Göstergelerden kararlara rehber

Hangi Uç Noktayı Önce Güvence Altına Almalısınız?

Her uç nokta aynı riski taşımaz. Kaynakları önce en riskli uçlara harcamak için olasılık ve etkiyi 1–3 ölçeğinde puanlayıp çarpmak yeterli bir ilk sıralama verir.

Örnekte giriş ve sipariş uçları 9 puanla başa gelir; hız sınırı, nesne yetkisi ve izleme önce oraya yatırılır. Puanlama zamanla güncellenir: yeni özellik ya da yeni saldırı türü sıralamayı değiştirir.

Yayın Öncesi API Güvenliği Kontrol Listesi Nedir?

Aşağıdaki maddeleri her büyük sürümde işaretleyin. Cevabı "hayır" olan her madde, kapatılması gereken bir açıktır.

• Tüm trafik güncel bir TLS sürümüyle şifreleniyor ve şifresiz bağlantı kapalı mı?
• Her uçta kimlik doğrulama var mı; açık bırakılan uçlar bilinçli bir kararla mı açık?
• Nesne sahipliği her istekte token'daki kimliğe göre denetleniyor mu?
• Token ömrü kısa mı, yenileme belirteci iptal edilebiliyor mu?
• Sırlar kaynak koddan ve günlükten uzak, sır yönetim aracında mı?
• Giriş, parola sıfırlama ve kod doğrulama uçlarında hız sınırı ve hesap kilidi var mı?
• Girdiler şemaya göre doğrulanıyor, yanıtlar yalnız gerekli alanları döndürüyor mu?
• Webhook istekleri imza ve zaman damgasıyla doğrulanıyor mu?
• Her istek kaydediliyor, olağandışı oranlar için uyarı tanımlı mı?
• Güvenlik testi ve yetki testleri yayın akışının parçası mı?

API Güvenliğinde Sık Yapılan Hatalar Nelerdir?

• Yetkiyi arayüze bırakmak: Düğmeyi gizlemek erişimi engellemez; denetim sunucuda yapılır.
• Kimliği istemciden almak: İstekteki kullanıcı numarasına güvenmek, başkasının verisine kapı açar.
• Anahtarı kaynak koda yazmak: Depoya giren sır sızmış sayılır.
• Sınırsız ömürlü token vermek: Bir kez sızan anahtar sonsuza dek geçerli kalır.
• Eski sürümü açık bırakmak: Kullanılmayan eski uç nokta, güvenlik güncellemesi almadığı için en zayıf halka olur.
• Hata ayrıntısını dışarı vermek: Yığın izi saldırgana sistem hakkında ipucu verir.
• İzlemeyi sonraya bırakmak: Kayıt yoksa olay geriye dönük incelenemez.

Güvenlik, bir yayın sonrası işi değil, tasarım kararıdır; bir saldırıdan sonra veriyi geri getirme tarafı ise ayrı bir konudur ve veri yedekleme rehberimizde ele alınmıştır.

Okumanızı öneririz: Mikroservis mimarisi nedir? Monolit farkı, maliyet ve karar rehberi

Okumanızı öneririz: Rol Bazlı Yetkilendirme (RBAC) Nedir?

İnovabil ile Güvenli API ve Entegrasyon Geliştirme

İnovabil olarak API ve entegrasyonları işletmenize özel yazıyoruz: pazaryeri, e-Fatura, kargo ve ERP bağlantıları, bayi portalı ve mobil uygulama arka uçları. Güvenlik gereksinimlerini, yani rol bazlı yetkiyi, denetim kayıtlarını ve güvenli barındırmayı baştan gereksinim analizine yazıyor; parçalı geliştirme ve kabul testiyle ilerliyoruz.

Kredili Kargo için kargo sistemi, İZBAN için satın alma sistemi ve Avcılar İnşaat için CRM, satın alma ve mobil uygulama geliştirdik; Karyak, Sleepy ve Bofigo için de lojistik, depo ve sevkiyat çözümleri yaptık. Mevcut bir API'nin güvenliğini gözden geçirmek ya da yeni bir entegrasyonu güvenli kurmak istiyorsanız akışı birkaç cümleyle anlatın; önce risk listesini ve öncelikleri yazılı olarak çıkaralım.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular