API Güvenliği Nedir? Güvenli API Geliştirme Rehberi

Bir uygulamada kullanıcıların giriş yapabilmesi, bütün verilerin güvende olduğu anlamına gelmez. Oturum açmış bir kullanıcı başka bir müşterinin siparişini görüntüleyebiliyor veya kendisine tanımlanmayan bir işlemi gerçekleştirebiliyorsa API katmanında önemli bir güvenlik sorunu vardır.

API güvenliği, uygulamalar arasında veri alışverişini sağlayan arayüzlerin yetkisiz erişime, veri sızıntısına ve kötüye kullanıma karşı korunmasıdır. Güvenli bir tasarım; kimlik doğrulama, yetkilendirme, veri kontrolü, kaynak sınırları ve izleme süreçlerini birlikte ele alır.

Bu rehberde, backend geliştirirken dikkat edilmesi gereken temel noktaları pratik örneklerle inceleyeceğiz.

API güvenliği neden önemlidir?

Mobil uygulamalar, e-ticaret platformları ve kurumsal sistemler birçok işlemi API üzerinden gerçekleştirir. Kullanıcı ekranında yalnızca bir buton görünse de arka planda veri okuyan, kayıt değiştiren veya ücretli bir hizmeti çağıran istekler çalışır.

Bu nedenle güvenlik değerlendirmesi, arayüzde hangi işlemlerin gösterildiğiyle sınırlı kalmamalıdır. API, kendisine doğrudan gönderilen istekleri de denetlemelidir.

OWASP’ın API Security Top 10 2023 listesinde nesne düzeyinde yetkilendirme eksiklikleri, bozuk kimlik doğrulama ve sınırsız kaynak tüketimi gibi riskler yer alır. Bu sınıflandırma, geliştirme sırasında hangi kontrollerin gözden geçirilmesi gerektiğini belirlemek için yararlı bir başlangıçtır. OWASP API Security Top 10

1. Kimlik doğrulama ile yetkilendirmeyi ayrı değerlendirin

Kimlik doğrulama, isteği gönderen kişinin kim olduğunu belirler. Yetkilendirme ise bu kişinin hangi verilere erişebileceğini ve hangi işlemleri yapabileceğini belirler.

Örneğin bir sipariş API’sini düşünelim:

GET /api/orders/125

Kullanıcının geçerli bir oturuma sahip olması, 125 numaralı siparişi görüntüleyebileceği anlamına gelmez. Sunucu, kullanıcının ilgili sipariş üzerinde erişim hakkı bulunup bulunmadığını da kontrol etmelidir.

Kullanıcı sipariş numarasını değiştirdiğinde başka bir müşterinin bilgilerine ulaşabiliyorsa nesne düzeyinde yetkilendirme açığı oluşur. OWASP bu riski Broken Object Level Authorization, kısaca BOLA olarak adlandırır.

Kontrol yalnızca görüntüleme işlemlerinde uygulanmamalıdır. Güncelleme, silme ve dışa aktarma işlemleri de kendi yetki kurallarına tabi olmalıdır. Tahmin edilmesi zor kimlikler kullanmak yardımcı olabilir; ancak erişim denetiminin yerini tutmaz. OWASP: Nesne düzeyinde yetkilendirme

2. HTTPS ve token doğrulamasını doğru yapılandırın

REST API güvenliği için veri aktarımı HTTPS üzerinden yapılmalıdır. Böylece erişim bilgileri ve gönderilen içerik, aktarım sırasında korunur.

JWT kullanıyorsanız token içeriğini okumak yeterli değildir. Sunucu, imzayı ve beklenen algoritmayı doğrulamalı; geçerlilik süresini, token’ı üreten tarafı ve hedef alıcıyı denetlemelidir.

Özellikle şu alanlar önem taşır:

• exp: Token’ın geçerlilik süresinin sonu.
• iss: Token’ı üreten taraf.
• aud: Token’ın kullanılmasının amaçlandığı alıcı.
• nbf: Token’ın geçerli olmaya başlayacağı zaman.

Çıkış yapma veya oturumun sonlandırılması durumunda token’ın nasıl geçersiz kılınacağı da tasarlanmalıdır. OWASP REST güvenliği rehberi

3. İstek sayısını ve kaynak tüketimini sınırlayın

Bir API isteğinin maliyeti yalnızca sunucunun verdiği yanıttan oluşmaz. İstek; SMS gönderimi, dosya işleme veya üçüncü taraf servis kullanımı gibi ek kaynakları da tüketebilir.

Örneğin şifre sıfırlama işlevinin kontrolsüz çağrılması, mesaj gönderim maliyetini artırabilir. Büyük raporların sürekli oluşturulması ise uygulamanın diğer kullanıcılarına ayrılan kaynakları azaltabilir.

Koruma tasarlarken şu sınırları birlikte değerlendirin:

• Belirli sürede kabul edilen istek sayısı.
• Yüklenebilecek dosyanın boyutu.
• Tek yanıtta döndürülebilecek kayıt sayısı.
• İşlemin çalışabileceği azami süre.
• Kullanıcı veya müşteri başına kaynak kotası.

Sınırları, uç noktanın maliyetine ve kullanım amacına göre belirleyin. OWASP: API riskleri ve kaynak tüketimi

4. Gelen veriyi doğrulayın, dönen veriyi sınırlandırın

İsteklerde beklenen veri türünü, uzunluğu, aralığı ve içerik biçimini sunucu tarafında doğrulayın. Kullanıcı arayüzündeki kontroller, API’ye doğrudan gönderilen istekleri engellemez.

Hata yanıtlarında yığın izleri, sistem ayrıntıları veya iç bağlantı bilgileri göstermeyin. İstemciye işlemi anlamlandırabileceği bir hata mesajı verin. OWASP REST güvenliği rehberi

Ayrıca bir kayda erişim hakkı bulunması, kaydın bütün alanlarını görme veya değiştirme hakkı bulunduğu anlamına gelmez. Örneğin profil güncelleyen bir kullanıcıya yönetici rolünü belirleyen alanı değiştirme yetkisi verilmemelidir. API yanıtları ve güncellenebilir alanlar bu ayrımla tasarlanmalıdır. OWASP: Nesne özellikleri düzeyinde yetkilendirme

5. Güvenlik olaylarını izlenebilir hâle getirin

API güvenliği, şüpheli davranışları fark edebilmeyi de kapsar. Başarısız girişler, reddedilen erişim girişimleri ve önemli yetki değişiklikleri, olay incelemesinde değerli bilgiler sağlayabilir.

Kayıtların anlamlı olması için olay zamanı, işlem türü, ilgili kullanıcı veya servis ve işlemin sonucu gibi bilgiler tutarlı biçimde kaydedilmelidir. İstek kimliği kullanmak, farklı servislerdeki kayıtları ilişkilendirmeyi kolaylaştırır.

Bununla birlikte parolalar, erişim token’ları ve gizli anahtarlar loglara yazılmamalıdır. Loglara erişim sınırlandırılmalı ve kayıtlar yetkisiz değişikliklere karşı korunmalıdır. OWASP loglama rehberi

Kayıtların olay incelemesinde nasıl kullanılabileceğini öğrenmek için Siber Olay Müdahale Süreci ve Log Analizi Teknikleri yazısını da okuyabilirsiniz.

Örnek API güvenlik testi nasıl planlanır?

Bir sipariş uygulamasında test planını yalnızca başarılı istekler üzerinden kurmayın. Örnek bir değerlendirme için farklı yetkilere sahip iki test kullanıcısı ve ayrı siparişler oluşturabilirsiniz.

Beklenen davranışları önceden tanımlayın:

Test senaryosu	Beklenen davranış
Kullanıcı kendi siparişini görüntüler	Yetkisi kapsamında erişebilir.
Kullanıcı başka müşterinin siparişini ister	Sipariş içeriği açıklanmaz.
Salt okuma yetkili kullanıcı siparişi değiştirmeye çalışır	Değişiklik yapılmaz.
Geçersiz token ile korunan uç nokta çağrılır	İstek kabul edilmez.
İstek, tanımlanan kullanım sınırını aşar	Belirlenen sınırlama uygulanır.

Bu örnek matrisi projenizin iş kurallarına göre genişletebilirsiniz. Her senaryoda hem yanıtı hem de veride istenmeyen bir değişiklik oluşup oluşmadığını kontrol etmek, incelemeyi daha somut hâle getirir.

Sıkça sorulan sorular

API güvenliği için HTTPS yeterli mi?

HTTPS aktarım güvenliğini sağlar. Kullanıcının hangi kayıtlara erişebileceği ve hangi işlemleri yapabileceği ayrıca denetlenmelidir. OWASP REST güvenliği rehberi

UUID kullanmak yetkilendirme açığını kapatır mı?

Hayır. Kimliklerin tahmin edilmesini zorlaştırmak, ilgili kayda erişim hakkını kontrol etmenin yerini tutmaz. OWASP BOLA rehberi

API loglarına bütün istek içeriği yazılmalı mı?

Kayıt kapsamı ihtiyaca göre belirlenmelidir. Parola ve erişim token’ı gibi hassas bilgiler loglara alınmamalı; kişisel veriler için maskeleme veya hariç tutma uygulanmalıdır. OWASP loglama rehberi

Geliştirdiğiniz API’yi değerlendirirken tek bir uç noktadan başlayabilirsiniz: Kim çağırabiliyor, hangi kayda erişiyor, hangi alanları değiştirebiliyor ve işlem nasıl izleniyor? Bu sorulara vereceğiniz somut yanıtlar, güvenlik kontrollerini uygulamanın gerçek davranışıyla karşılaştırmanızı sağlar.