API Güvenliği Rehberi: 8 Kritik Kontrol

Bir müşteri portalında tek bir yetki kontrolünün atlanması, başka bir müşterinin faturalarının, siparişlerinin veya çalışan verilerinin görüntülenmesine yol açabilir. API güvenliği rehberi hazırlamak bu nedenle yalnızca teknik ekiplerin kontrol listesi değildir. Gelir akışını, müşteri güvenini, operasyon sürekliliğini ve düzenleyici uyumu koruyan doğrudan bir iş gereksinimidir.

API'ler; web uygulamaları, mobil istemciler, iş ortakları, ödeme sistemleri, ERP çözümleri ve AI agent'ları arasında veri taşır. Bu erişim katmanı büyüdükçe saldırı yüzeyi de büyür. Hedef, API'yi dış dünyaya kapatmak değildir. Hedef, doğru kullanıcının doğru veriye doğru kapsamda ve izlenebilir biçimde erişmesini sağlamaktır.

API Güvenliği Neden İş Riski Olarak Ele Alınmalı?

Bir API ihlali çoğu zaman uygulamanın tamamen çökmesiyle başlamaz. Daha sık görülen senaryo, yetkisi olmayan bir kullanıcının tahmin edilebilir bir kaynak kimliği üzerinden başka bir kayda erişmesidir. Örneğin, `/orders/10452` çağrısındaki numarayı değiştiren kullanıcı başka bir müşterinin siparişine ulaşabiliyorsa, kimlik doğrulama yapılmış olsa bile yetkilendirme tasarımı başarısızdır.

Bu tür açıkların maliyeti yalnızca olay müdahalesi değildir. Müşteri kaybı, sözleşmesel yükümlülükler ve ekiplerin plansız düzeltme çalışmaları da maliyete eklenir. DACH pazarında veya Türkiye'de kişisel ve ticari verilerle çalışan şirketler için veri minimizasyonu, erişim kayıtları ve saklama politikaları da güvenlik kararının parçasıdır.

API güvenliği, hız ile güvenlik arasında zorunlu bir karşıtlık yaratmamalıdır. İyi tasarlanmış merkezi kontroller, ekiplerin her yeni endpoint'te aynı temel kuralları yeniden yazmasını önler. Böylece ürün ekipleri daha hızlı teslimat yaparken denetim ve risk yönetimi daha görünür hale gelir.

1. Kimlik Doğrulamayı Erişim Kontrolüyle Karıştırmayın

Kimlik doğrulama, çağrıyı yapanın kim olduğunu doğrular. Yetkilendirme ise bu kimliğin ne yapabileceğini belirler. İkisi ayrılmadığında, giriş yapmış her kullanıcının gereğinden geniş erişim elde etmesi kolaylaşır.

Kullanıcı odaklı uygulamalarda OAuth 2.0 ve OpenID Connect, modern ve yönetilebilir bir temel sunar. Kısa ömürlü erişim belirteçleri, yenileme akışı ve açık kapsamlar sayesinde erişim kararları daha kontrollü yürütülür. Makineden makineye iletişimde istemci kimlik bilgileri kullanılabilir; ancak her servis için ayrı kimlik ve mümkün olan en dar izin seti tanımlanmalıdır.

API anahtarları pratik görünür, fakat tek başına kullanıcı kimliğini veya ayrıntılı yetki bağlamını taşımaz. Bu nedenle düşük riskli, sınırlı entegrasyonlar dışında API anahtarlarını ana güvenlik mekanizması olarak konumlandırmak doğru değildir. Kullanıldıklarında anahtarlar kullanıcıya değil entegrasyona bağlanmalı, rotasyona tabi tutulmalı ve asla kaynak koduna, istemci uygulamasına veya loglara yazılmamalıdır.

2. Her Kaynak İçin Nesne Düzeyinde Yetki Denetimi Yapın

En sık görülen API zafiyetlerinden biri BOLA olarak da anılan nesne düzeyinde yetkilendirme eksikliğidir. Uygulama kullanıcının geçerli bir belirtece sahip olduğunu kontrol eder, ancak talep ettiği kaynağın gerçekten ona ait olup olmadığını doğrulamaz.

Bu kontrol yalnızca kullanıcı rolüyle çözülemez. "Muhasebe kullanıcısı" rolü, her faturayı görme hakkı anlamına gelmeyebilir. Yetki kararı; kullanıcı, organizasyon, kaynak sahibi, işlem türü ve sözleşme kapsamını birlikte değerlendirmelidir.

Pratikte bu mantığı endpoint'lere dağılmış koşullar yerine merkezi bir yetkilendirme katmanında toplamak daha güvenlidir. Politika tabanlı erişim kontrolü, yeni roller veya kurumsal müşteri yapıları eklendiğinde değişiklik maliyetini düşürür. Kritik işlemler için ikinci onay, işlem limiti veya ek doğrulama da gerekebilir.

3. Girdi ve Çıktı Verisini Ayrı Ayrı Yönetin

Bir istemciden gelen JSON alanlarını doğrudan veri modeline bağlamak, beklenmeyen alanların güncellenmesine neden olabilir. Örneğin kullanıcı profilini güncelleyen bir endpoint'in `role`, `creditLimit` veya `isApproved` gibi alanları kabul etmesi ciddi bir yetki yükseltme riskidir.

Her endpoint için açık bir istek şeması tanımlayın. Tip, uzunluk, biçim, izin verilen değerler ve zorunlu alanlar sunucu tarafında doğrulanmalıdır. İstemci tarafı doğrulaması kullanıcı deneyimi için değerlidir, ancak güvenlik kontrolü değildir.

Çıktı tarafı en az girdi kadar kritiktir. Veritabanı nesnesini olduğu gibi döndürmek yerine, her kullanım senaryosu için tasarlanmış yanıt modelleri kullanın. Özellikle erişim belirteçleri, parola sıfırlama verileri, iç sistem kimlikleri ve gereksiz kişisel veriler yanıtlardan çıkarılmalıdır.

4. Trafiği Sınırlayın, Ama Meşru Kullanımı Bozmayın

Oran sınırlama, parola denemeleri, veri toplama girişimleri ve maliyetli sorgulara karşı temel savunmadır. Ancak herkese aynı limit uygulamak, yoğun kullanım yapan gerçek müşterileri de engelleyebilir. Limitleri IP adresi, kullanıcı hesabı, API istemcisi, endpoint hassasiyeti ve müşteri planı gibi sinyallere göre katmanlı tasarlamak daha sağlıklıdır.

Giriş, OTP doğrulama, parola sıfırlama ve arama uçları daha sıkı sınırlamalara ihtiyaç duyar. Rapor üretme veya büyük veri dışa aktarma gibi maliyetli işlemlerde ise kuyruk yapısı, kota yönetimi ve asenkron işleme tercih edilebilir. Bir API gateway; TLS zorlaması, oran sınırlama ve merkezi loglama için değerli bir noktadır — ancak uygulama içindeki nesne düzeyinde yetki denetiminin yerine geçmez.

5. Sırları, Anahtarları ve Servis Erişimlerini Yönetin

Üretim veritabanı parolalarının veya üçüncü taraf servis anahtarlarının ortam değişkenlerinde bile sınırsız süreyle kalması kabul edilebilir bir süreç değildir. Merkezi bir secret management çözümü, erişim kayıtları, kısa ömürlü kimlik bilgileri ve düzenli rotasyon ile risk azaltılmalıdır.

Geliştirme, test ve üretim ortamları kesin olarak ayrılmalıdır. Test ortamının gerçek müşteri verisini taşıması kısa vadede kolaylık sağlasa da ihlal etkisini gereksiz biçimde artırır. Ayrıca servis hesapları için en az ayrıcalık ilkesi uygulanmalıdır: her erişim için "Bu izin olmasa hangi işlev bozulur?" sorusu sorulmalıdır.

6. İzlenebilirlik Olmadan Güvenlik Yönetilemez

Başarılı bir saldırı girişimi, yalnızca hata kodu olarak kalmamalıdır. Kim, hangi istemciyle, hangi kaynağa, ne zaman ve hangi sonuçla erişti? Bu soruları yanıtlayan yapılandırılmış kayıtlar olay analizi için gereklidir. Ancak loglara erişim belirteci, parola veya gereksiz kişisel veri yazılmamalıdır.

Şüpheli davranış sinyalleri için uyarılar tanımlayın: kısa sürede çok sayıda başarısız giriş, art arda kaynak kimliği denemeleri veya olağandışı hacimde dışa aktarma gibi. Kimin müdahale edeceği ve erişimin nasıl geçici olarak kesileceği önceden belirlenmelidir.

7. Güvenliği Teslimat Sürecine Yerleştirin

Yayın öncesi yapılan tek seferlik penetrasyon testi değerlidir, fakat sürekli değişen API için tek başına yeterli değildir. Yeni bir endpoint tasarlanırken veri sınıflandırması, kimlik doğrulama yöntemi, gerekli roller ve oran limiti birlikte kararlaştırılmalıdır. Otomatik testler, başka bir organizasyona ait kaynağa erişim denemeleri gibi negatif senaryoları da kapsamalıdır.

Bağımlılık taraması, gizli anahtar taraması ve API şema değişikliklerinin denetlenmesi, CI/CD hattında çalışan somut kontrollerdir. İnsan incelemesini ortadan kaldırmazlar; tekrarlayan hataları üretime ulaşmadan yakalayarak mühendislik zamanını daha değerli kararlar için serbest bırakırlar.

8. AI ve Entegrasyon Senaryolarında Sınırı Net Çizin

AI agent'ları API üzerinden CRM kaydı açıyor, rapor çekiyor veya işlem başlatıyorsa, agent'a sınırsız servis hesabı yetkisi vermek yüksek risktir. Agent'ın çağırabileceği araçlar, veri kapsamı ve insan onayı gerektiren eylemler açık biçimde tanımlanmalıdır; modelin önerisi ile sistemin gerçekleştirdiği işlem birbirinden ayrılmalı, yüksek etkili eylemler deterministik politika kontrollerinden geçmelidir. Bu ayrımı ve talimat enjeksiyonu risklerini Yapay Zeka Ajanı Güvenli mi? Riskler ve Kontroller yazımızda ayrıntılı ele aldık.

API güvenliği olgunlaştıkça ürün ekibi daha az acil düzeltme yapar, operasyon ekipleri daha güvenilir verilere dayanır ve müşterilerle yapılan entegrasyon görüşmeleri daha net ilerler. Yeni bir API veya AI destekli iş akışı planlarken, ilk teknik tasarım oturumunda erişim sınırlarını ve olay senaryolarını masaya koymak, sonradan yapılacak pahalı düzeltmelerden çok daha etkili bir yatırımdır.

Kendi API güvenlik mimarinizi birlikte tasarlamak isterseniz, projenizi bize anlatın.