BMK

API Güvenliğinde En İyi Pratikler

RESTful API'lerinizi güvenli hale getirmek için uygulamanız gereken temel güvenlik önlemleri.

MKMurat K.5 dk okumaGüvenlik
Turkuaz ışıklı devre kartı paneli
Fotoğraf: Adi Goldstein / Unsplash

API güvenliği, kurumsal yazılım mimarisinin en kritik başlıklarından biri haline geldi. Web ve mobil uygulamalar, iş ortaklarıyla yapılan entegrasyonlar ve iç sistemler arasındaki veri akışı büyük ölçüde RESTful API'ler üzerinden yürüyor. Bu da API'leri, saldırganlar için kurumun verilerine ve iş süreçlerine açılan doğrudan bir kapı haline getiriyor.

Bir web sayfasındaki açık genellikle tek bir ekranı etkilerken, korunmasız bir API uç noktası çok sayıda kaydın toplu şekilde dışarı sızmasına yol açabilir. Bu yazıda RESTful API'lerinizi güvenli hale getirmek için uygulamanız gereken temel önlemleri; kimlik doğrulama ve yetkilendirmeden hız sınırlamaya, girdi doğrulamadan gizli anahtar yönetimine kadar pratik bir çerçevede ele alıyoruz.

OWASP API Security Top 10 (2023): API Güvenliğinin Referans Listesi

OWASP (Open Worldwide Application Security Project), API'lere özgü riskleri ayrı bir liste olarak yayımlar. 2023 yılında güncellenen OWASP API Security Top 10, API güvenliği çalışmalarına başlamak için iyi bir kontrol listesi sunar. Listenin 2023 sürümündeki başlıklar şunlardır:

  1. 1API1: Broken Object Level Authorization (nesne düzeyinde hatalı yetkilendirme)
  2. 2API2: Broken Authentication (hatalı kimlik doğrulama)
  3. 3API3: Broken Object Property Level Authorization (nesne özelliği düzeyinde hatalı yetkilendirme)
  4. 4API4: Unrestricted Resource Consumption (sınırsız kaynak tüketimi)
  5. 5API5: Broken Function Level Authorization (fonksiyon düzeyinde hatalı yetkilendirme)
  6. 6API6: Unrestricted Access to Sensitive Business Flows (hassas iş akışlarına sınırsız erişim)
  7. 7API7: Server Side Request Forgery (sunucu taraflı istek sahteciliği, SSRF)
  8. 8API8: Security Misconfiguration (hatalı güvenlik yapılandırması)
  9. 9API9: Improper Inventory Management (yetersiz API envanter yönetimi)
  10. 10API10: Unsafe Consumption of APIs (üçüncü taraf API'lerin güvensiz kullanımı)

Listenin ilk sıralarında yetkilendirme hatalarının yer alması dikkat çekicidir. Bu durum, API güvenliğindeki sorunların çoğu zaman karmaşık saldırı tekniklerinden değil, temel erişim kontrollerinin eksik uygulanmasından kaynaklandığını hatırlatır.

API Kimlik Doğrulama ve Yetkilendirme: OAuth 2.0 ve JWT

Kimlik doğrulama (authentication) isteği yapanın kim olduğunu, yetkilendirme (authorization) ise bu kişinin neye erişebileceğini belirler. İkisi farklı sorunları çözer ve ikisinin de eksiksiz uygulanması gerekir.

OAuth 2.0 ile standartlara dayalı yetkilendirme

Kullanıcı adına üçüncü taraf uygulamalara erişim verilmesi veya merkezi kimlik yönetimi gereken senaryolarda kendi protokolünüzü geliştirmek yerine OAuth 2.0 ve onun üzerine kurulu OpenID Connect gibi yerleşik standartları kullanmak çok daha güvenlidir. Web ve mobil istemciler için PKCE ile birlikte Authorization Code akışı önerilen yaklaşımdır; eski Implicit akışı ise güncel güvenlik önerilerinde artık tavsiye edilmemektedir. Sunucular arası iletişimde Client Credentials akışı tercih edilebilir.

JWT kullanırken sık yapılan hatalar

JSON Web Token (JWT), yaygın kullanılan bir erişim belirteci formatıdır; ancak yanlış yapılandırıldığında ciddi açıklara yol açabilir.

  • İmza algoritmasını sabitlememek: Sunucu kabul ettiği algoritmayı açıkça belirlemeli; none algoritmasıyla gelen veya beklenmeyen bir algoritmayla imzalanmış tokenlar reddedilmelidir.
  • Zayıf veya koda gömülü imza anahtarları: Tahmin edilebilir anahtarlar, tokenların sahtelenmesine imkan verir.
  • Uzun ömürlü erişim tokenları: Erişim tokenlarının ömrünü kısa tutun; uzun oturumlar için yenileme (refresh) tokenları kullanın.
  • Token içine hassas veri koymak: JWT içeriği varsayılan olarak şifrelenmez, yalnızca imzalanır ve kolayca okunabilir.
  • exp, iss ve aud alanlarını kontrol etmemek: Tokenın süresi, yayıncısı ve hedef kitlesi her istekte doğrulanmalıdır.

Nesne ve fonksiyon düzeyinde yetkilendirme

Kullanıcının oturum açmış olması, her kayda erişebileceği anlamına gelmez. Örneğin /orders/1234 adresine istek yapan kullanıcının bu siparişin gerçekten sahibi olup olmadığı sunucu tarafında her istekte kontrol edilmelidir. Benzer şekilde yönetici işlevleri sunan uç noktalar, yalnızca arayüzde gizlenerek değil, sunucu tarafındaki rol kontrolleriyle korunmalıdır.

Rate Limiting ile API Kötüye Kullanımını Önleme

Hız sınırlama (rate limiting), bir istemcinin belirli bir süre içinde yapabileceği istek sayısını kısıtlar. Kaba kuvvet (brute force) giriş denemelerini, veri kazıma girişimlerini ve kaynak tüketimine dayalı hizmet kesintilerini önlemenin temel yollarından biridir.

  • Sınırları IP adresi, kullanıcı veya API anahtarı bazında tanımlayın.
  • Giriş, şifre sıfırlama ve tek kullanımlık kod doğrulama gibi hassas uç noktalara daha sıkı limitler uygulayın.
  • Sınır aşıldığında HTTP 429 (Too Many Requests) yanıtı dönün ve gerekiyorsa Retry-After başlığını kullanın.
  • İstek gövdesi boyutu, sayfa başına kayıt sayısı ve dosya yükleme boyutu gibi kaynak sınırlarını da belirleyin.

Bu kontroller genellikle API Gateway veya ters proxy katmanında merkezi olarak uygulanır; böylece her serviste ayrı ayrı yazılması gerekmez ve politikalar tek noktadan yönetilir.

Girdi Doğrulama ve Veri Maruziyetini Sınırlama

API'ye gelen hiçbir veriye körü körüne güvenilmemelidir. İstemci tarafında yapılan doğrulamalar kullanıcı deneyimi içindir; güvenlik açısından asıl kontrol sunucu tarafında yapılmalıdır.

  • İstek gövdelerini OpenAPI veya JSON Schema gibi tanımlı bir şemaya göre doğrulayın; beklenmeyen alanları reddedin.
  • Veri tabanı sorgularında parametreli sorgular veya güvenilir ORM yöntemleri kullanarak SQL enjeksiyonunu önleyin.
  • İstemciden gelen alanların doğrudan veri modeline aktarılmasına (mass assignment) izin vermeyin; rol veya bakiye gibi alanlar kullanıcı tarafından değiştirilememelidir.
  • Yanıtlarda yalnızca gerekli alanları döndürün; tüm nesneyi gönderip filtrelemeyi istemciye bırakmayın.
  • Hata mesajlarında yığın izi (stack trace), veri tabanı ayrıntıları veya iç sistem bilgileri göstermeyin.

HTTPS/TLS ve Gizli Anahtar Yönetimi

API trafiğinin tamamı, iç ağda bile, HTTPS üzerinden şifrelenmelidir. Güncel öneriler TLS 1.2 ve 1.3 sürümlerinin kullanılmasını, eski protokol sürümleri ile zayıf şifre takımlarının devre dışı bırakılmasını kapsar. HSTS başlığı, tarayıcı tabanlı istemcilerin bağlantıyı düz HTTP'ye düşürmesini engeller. Servisler arası iletişimde karşılıklı TLS (mTLS), istemcinin kimliğini de doğrulamak için güçlü bir seçenektir.

Veri tabanı parolaları, API anahtarları ve imza anahtarları gibi gizli bilgiler kaynak koda, yapılandırma dosyalarına veya sürüm kontrol sistemine yazılmamalıdır. Bunun yerine HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault gibi gizli anahtar yönetim araçları ya da en azından ortam değişkenleri kullanılmalıdır. Anahtarlar düzenli aralıklarla yenilenmeli ve her servise yalnızca ihtiyaç duyduğu yetki verilmelidir.

API Loglama, İzleme ve Envanter Yönetimi

Saldırıyı engellemek kadar fark edebilmek de önemlidir. Başarısız giriş denemeleri, yetkilendirme hataları, olağandışı istek hacimleri ve hata oranlarındaki ani artışlar merkezi bir log sisteminde toplanmalı ve alarm kurallarıyla izlenmelidir. Loglara parola, token veya kişisel veri yazılmamasına özellikle dikkat edilmeli; KVKK kapsamındaki yükümlülükler de bu konuda göz önünde bulundurulmalıdır.

OWASP listesindeki envanter yönetimi maddesi de bu başlıkla yakından ilgilidir. Unutulmuş test ortamları, eski API sürümleri veya belgelenmemiş uç noktalar çoğu zaman güvenlik güncellemelerinin dışında kalır. Tüm API'lerin, sürümlerinin ve sorumlularının güncel bir envanterini tutmak ve kullanılmayan uç noktaları kapatmak bu riskin önüne geçer.

Sonuç

API güvenliği tek seferlik bir yapılandırma değil, tasarım aşamasında başlayıp canlı ortamda sürekli izlemeyle devam eden bir süreçtir. Doğru kimlik doğrulama ve yetkilendirme, hız sınırlama, sıkı girdi doğrulama, şifreli iletişim, güvenli anahtar yönetimi ve etkin izleme bir araya geldiğinde API'leriniz saldırılara karşı çok daha dayanıklı hale gelir. OWASP API Security Top 10 listesini düzenli bir kontrol aracı olarak kullanmak ve güvenlik testlerini geliştirme sürecine dahil etmek iyi bir başlangıç noktasıdır.

BMK Yazılım, kurumların API ve sistem entegrasyonu projelerinde güvenliği tasarımın ilk aşamasından itibaren ele alan çözümler geliştirmektedir.

Sık sorulan sorular

API güvenliği nedir?

API güvenliği, uygulamalar arasında veri alışverişi sağlayan arayüzlerin yetkisiz erişime, veri sızıntısına ve kötüye kullanıma karşı korunmasıdır. Kimlik doğrulama, yetkilendirme, girdi doğrulama, şifreleme, hız sınırlama ve izleme gibi önlemlerin bir arada uygulanmasını kapsar.

JWT mi yoksa oturum (session) tabanlı kimlik doğrulama mı kullanılmalı?

İkisi de doğru uygulandığında güvenlidir. JWT, dağıtık mimarilerde ve servisler arası iletişimde pratiklik sağlarken, sunucu tarafı oturumlar oturumun anında sonlandırılmasını kolaylaştırır. Seçim mimarinize bağlıdır; JWT kullanıyorsanız kısa ömürlü tokenlar ve sıkı doğrulama kuralları şarttır.

API anahtarı tek başına yeterli bir güvenlik önlemi mi?

Genellikle hayır. API anahtarı istemciyi tanımlamaya yarar, ancak kullanıcı bazında yetkilendirme sağlamaz ve sızdırıldığında kolayca kötüye kullanılabilir. Kullanıcı verisine erişen API'lerde OAuth 2.0 gibi standart yöntemlerle birlikte kullanılmalıdır.

Rate limiting nasıl uygulanır?

En yaygın yöntem, API Gateway, ters proxy veya uygulama katmanında istemci başına belirli bir zaman aralığında izin verilen istek sayısını tanımlamaktır. Sınır aşıldığında HTTP 429 yanıtı döndürülür. Hassas uç noktalar için daha sıkı limitler belirlenmesi önerilir.

MK

Yazar

Murat K.

BMK Yazılım ekibi

İlgili hizmetimiz

API & Sistem Entegrasyonu

Bu konuda kurumunuza özel çözümü birlikte planlayalım.

Tüm yazılar

Yeni proje

Birlikte yeni bir projeye başlayalım!

Yeni bir uygulama, mevcut sisteminiz için bir modül ya da birbirine bağlanması gereken sistemler… Ne istediğinizi anlatın, size uygun yolu ve tahmini süreyi birlikte çıkaralım.

Mesai saatlerinde gelen taleplere en geç 1 saat içinde dönüyoruz.

Süreç nasıl başlar?

  1. 01

    Tanışma görüşmesi

    İhtiyacınızı ve hedeflerinizi dinliyoruz; teknik bilgi gerekmez.

  2. 02

    İhtiyaç analizi

    Süreçlerinizi ve mevcut sistemlerinizi inceleyip kapsamı netleştiriyoruz.

  3. 03

    Teklif ve yol haritası

    Süre, bütçe ve teslim adımlarını içeren yazılı bir plan sunuyoruz.

E-postainfo@bmkteknoloji.com
OfisSarıyer, İstanbul
Konuşalım✳
Konuşalım✳
Konuşalım✳
Konuşalım✳