API Güvenliği ve API Gateway

API Güvenliği Neden Önemlidir?

API'lerin bilişim sektöründe bu denli kritik öneme sahip olması ve iki uygulama arasındaki iletişimin tam merkezinde yer alması, onları siber suçlular açısından muazzam bir hedef haline getirmiştir. Modern mimarilerde API'ler; hassas verileri işler, finansal işlemleri yönetir ve servisler arası kritik işlevleri kontrol ederler. Bu nedenle API katmanında yaşanacak güvenlik açıkları büyük felaketlere yol açabilir.

Bir API yeterince korunmuyorsa aşağıdaki riskler ortaya çıkabilir:

• Hassas kullanıcı bilgilerinin ele geçirilmesi
• Yetkisiz kullanıcıların sisteme erişmesi
• Kimlik bilgilerinin çalınması
• Veri manipülasyonu
• Servisin gerçek kullanıcılar tarafından olmayan aşırı trafiğe maruz bırakılarak kullanılamaz hale getirilmesi (DDoS Saldırısı)
• İş mantığının kötüye kullanılması
• Finansal ve hukuki kayıplar

Geleneksel Güvenlik Çözümleri Neden Yetersiz Kalıyor?

Standart web uygulamalarında kullanıcı etkileşimi büyük oranda kullanıcı arayüzü (UI) üzerinden kontrol edilebiliyorken API katmanında istemci doğrudan ham veri ve iş mantığı ile muhattap olur. Geleneksel Ağ Güvenlik Duvarları (Firewall) ve Web Uygulama Duvarları (WAF), HTTP trafiğini imza tabanlı (signature-based) analiz ederek SQL Injection veya Cross-Site-Scripting (XSS) gibi bilinen saldırıları engellemede başarılıdır.

Ancak WAF'lar, uygulamanın iş mantığını bilmezler. Bir kullanıcının kendi yetki alanının dışındaki bir nesne kimliğini (ID) talep edip etmediğini ya da bir API fonksiyonunu manipüle edip etmediğini geleneksel yöntemlerle tespit etmek imkansızdır. Bu durum, siber saldırganlar için yepyeni ve suistimale açık alanlar yaratmaktadır.

not

Standart web uygulamalarında kullanıcı etkileşimi büyük oranda arayüz (UI) üzerinden kontrol edilebilirken, API katmanında istemci doğrudan veri ve iş mantığı (business logic) ile muhatap olur. Bu durum, siber saldırganlar için yeni suistimal alanları yaratmaktadır.

API Güvenliğinin Sağlanması ve OWASP

Bu kritik risklerle başa çıkabilmek ve API'leri korumanın en iyi yollarını keşfetmek amacıyla, uluslararası alanda bilişim güvenliği konusundaki en saygın otorite kabul edilen OWASP (Open Web Application Security Project), API'lerin kendilerine özgü tehdit mimarisini ele alan OWASP API Security TOP 10 listesini yayınlamıştır.

Aşağıda, bu en yaygın 10 zafiyetin teknik detaylarını ve bu zafiyetlerin merkezi bir API Gateway (API Geçidi) mimarisiyle proaktif olarak nasıl çözülebileceğini derinlemesine inceleyeceğiz;

OWASP API Security TOP 10

#1 Kırık Nesne Seviyesinde Yetkilendirme (Broken Object Level Authorization - BOLA)

API'lar, doğası gereği nesne tanımlayıcılarını (ID, UUID vb.) parametre olarak alan ve bu kimliklere göre veri sunan uç noktalara (endpoints) sahiptir. BOLA, sisteme giriş yapmış bir kullanıcının, istek attığı nesne kimliğini (örneğin /api/users/101 yerine /api/users/102) değiştirerek yetkisi dışındaki bir veriye erişebilmesi durumudur.

Bu zafiyet, günümüzde en kritik API güvenlik açıklarından biri olarak kabul edilmektedir. Çünkü saldırganın herhangi bir güvenlik mekanizmasını kırmasına gerek yoktur; yalnızca istekte bulunan nesne kimliğini değiştirmesi yeterlidir.

API Gateway Bu Riski Nasıl Azaltır?

API Gateway, BOLA zafiyetini tek başına tamamen engelleyemez. Çünkü bir kaynağın gerçekten ilgili kullanıcıya ait olup olmadığı bilgisi yalnızca uygulamanın iş mantığında bulunmaktadır.

Bununla birlikte API Gateway aşağıdaki güvenlik kontrollerini sağlayarak bu saldırının gerçekleşmesini önemli ölçüde zorlaştırabilir:

• JWT veya OAuth2 Access Token doğrulaması yaparak yalnızca kimliği doğrulanmış kullanıcıların API'ye erişmesini sağlar.
• Token içerisindeki kullanıcı bilgilerini (Claims) güvenilir şekilde Backend servislere iletir.
• Geçersiz, süresi dolmuş veya sahte token'ları daha Backend'e ulaşmadan engeller.
• Kullanıcı kimliği ile birlikte istekleri loglayarak şüpheli erişim denemelerinin tespit edilmesini kolaylaştırır.
• Aynı kullanıcı tarafından kısa sürede farklı nesne kimliklerine yapılan yoğun istekleri Rate Limiting politikalarıyla sınırlandırabilir.

#2 Kırık Kullanıcı Kimlik Doğrulaması (Broken Authentication)

Kimlik doğrulama (Authentication), API güvenliğinin temel taşlarından biridir. Broken Authentication, kullanıcıların kimliğini doğrulamak için kullanılan mekanizmaların hatalı veya eksik uygulanması sonucunda ortaya çıkan güvenlik zafiyetlerini ifade eder. Bu zafiyet, saldırganların başka kullanıcıların kimliklerini ele geçirmesine, geçerli oturumları kötüye kullanmasına veya sisteme yetkisiz erişim sağlamasına neden olabilir.

En yaygın kimlik doğrulama zafiyetleri şunlardır:

• JWT (JSON Web Token) imzasının doğrulanmaması
• Süresi dolmuş (Expired) Token'ların kabul edilmesi
• Zayıf veya tahmin edilebilir şifrelerin kullanılması
• Brute Force saldırılarına karşı koruma bulunmaması
• API Key'lerin güvensiz şekilde saklanması veya iletilmesi
• OAuth2 veya OpenID Connect yapılandırmalarının hatalı uygulanması

Kimlik doğrulama mekanizmasındaki tek bir hata, saldırganın uygulamaya meşru bir kullanıcı gibi erişebilmesine neden olabilir. Bu nedenle Authentication sürecinin merkezi, tutarlı ve güvenilir şekilde yönetilmesi kritik önem taşır.

API Gateway Bu Riski Nasıl Azaltır?

API Gateway, istemciden gelen tüm isteklerin ilk uğradığı nokta olduğundan kimlik doğrulama işlemlerini merkezi olarak gerçekleştirebilir. Böylece geçersiz veya güvenilmeyen istekler Backend servislere ulaşmadan engellenir.

API Gateway bu kapsamda aşağıdaki güvenlik kontrollerini sağlayabilir;

• JWT (JSON Web Token) imzasını doğrular ve sahte token'ları reddeder.
• Token'ın son kullanma tarihini (Expiration) kontrol ederek süresi dolmuş token'larla yapılan istekleri engeller.
• Token içerisindeki Issuer (iss) ve Audience (aud) bilgilerinin doğruluğunu kontrol eder.
• OAuth2 ve OpenID Connect sağlayıcıları ile entegre çalışarak merkezi kimlik doğrulaması gerçekleştirir.
• API Key doğrulaması yaparak yalnızca yetkilendirilmiş istemcilerin API'ye erişmesine izin verir.
• LDAP, Active Directory veya diğer kimlik yönetim sistemleriyle entegre çalışabilir.
• Aynı istemciden kısa süre içerisinde gelen yoğun giriş denemelerini Rate Limiting politikalarıyla sınırlandırarak Brute Force saldırılarının etkisini azaltabilir.
• Başarısız kimlik doğrulama girişimlerini kayıt altına alarak güvenlik ekiplerinin şüpheli aktiviteleri izlemesini kolaylaştırır.

ipucu

Kimlik doğrulamanın API Gateway üzerinde merkezi olarak gerçekleştirilmesi, tüm servislerde aynı güvenlik standartlarının uygulanmasını sağlar ve her mikroservisin kendi kimlik doğrulama mekanizmasını geliştirme ihtiyacını ortadan kaldırır.

#3 Kırık Nesne Özelliği Seviyesinde Yetkilendirme (Broken Object Property Level Authorization)

Broken Object Property Level Authorization (BOPLA), bir istemcinin erişmemesi veya değiştirmemesi gereken nesne özelliklerine (properties) erişebilmesi durumunda ortaya çıkan bir yetkilendirme zafiyetidir. Bu güvenlik açığı, istemcinin yalnızca belirli alanlara erişebilmesi gerekirken API'nin nesnenin tamamını döndürmesi veya istemciden gelen tüm alanları doğrulama yapmadan kabul etmesi sonucunda oluşur.

Bu zafiyet temel olarak iki farklı senaryoda karşımıza çıkar:

• Aşırı Veri Maruziyeti (Excessive Data Exposure): API, istemcinin ihtiyaç duyduğu alanlar yerine nesnenin tüm özelliklerini döndürür. Arayüz yalnızca gerekli alanları gösterse bile, saldırgan HTTP yanıtını inceleyerek hassas verilere ulaşabilir.
• Toplu Atama (Mass Assignment): API, istemciden gelen tüm alanları doğrudan veri modeline eşlediğinde saldırgan normal şartlarda değiştirmemesi gereken alanları isteğe ekleyebilir. Örneğin "role": "admin", "isAdmin": true veya "accountStatus": "ACTIVE" gibi kritik alanlar yetkisiz şekilde güncellenebilir.

Bu tür zafiyetler, kullanıcı yetkilerinin yükseltilmesine, hassas verilerin açığa çıkmasına ve uygulamanın iş kurallarının ihlal edilmesine neden olabilir.

API Gateway Bu Riski Nasıl Azaltır?

• JSON Schema Validation ve XML Schema Validation ile istek gövdelerinin (Request Body) önceden tanımlanmış şemalara uygun olup olmadığını doğrular. Bu sayede beklenmeyen veya izin verilmeyen alanlar içeren istekleri Backend servislere ulaşmadan reddedebilir.

• JSON Transformation ve XML Transforation ile JSON ve XML içeriklerini doğrulayarak bozuk veya beklenmeyen veri yapılarının istemciye ulaşmasını önleyebilir.

Bu kontroller sayesinde istemcinin yalnızca ihtiyaç duyduğu verilere erişmesi sağlanırken, kritik alanların istemci tarafından değiştirilmesi veya görüntülenmesi büyük ölçüde engellenebilir.

#4 Sınırsız Kaynak Tüketimi (Unrestricted Resource Consumption)

Modern API'ler, istemcilerden gelen her isteği işleyebilmek için CPU, bellek (RAM), ağ bant genişliği, veri tabanı bağlantıları ve disk gibi sistem kaynaklarını kullanır. Bu kaynakların kontrolsüz şekilde tüketilmesine izin verilmesi, API'nin performansının düşmesine veya tamamen hizmet veremez hale gelmesine neden olabilir.

Unrestricted Resource Consumption zafiyeti, API'nin istemcilerden gelen isteklerin sayısını, boyutunu veya işlem maliyetini sınırlandırmaması sonucunda ortaya çıkar. Bu durum yalnızca kötü niyetli saldırılarla değil, hatalı çalışan istemci uygulamaları veya beklenmeyen trafik artışları nedeniyle de meydana gelebilir.

Saldırganlar bu zafiyeti kullanarak;

• Saniyede binlerce HTTP isteği gönderebilir.
• Çok büyük boyutlu Request Body'leri ileterek sunucu kaynaklarını tüketebilir.
• Sayfalama (Pagination) uygulanmayan uç noktalardan milyonlarca kaydı tek istekte çekmeye çalışabilir.
• Yoğun veri tabanı sorguları oluşturan API çağrılarını sürekli tekrar ederek işlem kapasitesini tüketebilir.
• Aynı anda çok sayıda bağlantı (Connection) açarak diğer kullanıcıların servise erişmesini engelleyebilir.

Bu saldırılar sonucunda API'nin yanıt süreleri artabilir, hizmet kesintileri (DoS/DDoS) yaşanabilir ve özellikle bulut ortamlarında beklenmedik altyapı maliyetleri oluşabilir.

API Gateway Bu Riski Nasıl Azaltır?

• Rate Limiting (Throttling, Quota, Rate Limit Control List (RLCL)) ile belirli bir istemci ya da istemci grubunun belirli bir zaman aralığında gönderebileceği istek sayısını sınırlandırabilir.
• Time Restriction ile bir API'ye belirtilen saat aralığında isteklerin yönlendirilmesini ya da tam tersi olan belirtilen saat aralığında isteklerin yönlendirilmemesini Gateway üzerinde isteği keserek sağlayabilir.
• Max Message Size ile belirlenen boyutun üzerindeki istekleri reddedebilir.
• Min Message Size kullanarak aşırı büyük yanıtların istemciye gönderilmesini kontrol altına alabilir.
• Caching mekanizmasını kullanarak sık erişilen verilerin doğrudan Gateway üzerinden döndürülmesini sağlayabilir ve Backend üzerindeki yükü azaltabilir.
• IP White List ile bir API'ın sadece belirli IP'ler üzerinden tüketilebilmesini, Bu IP tanımları haricindeki IP'lerden gelen isteklerin Gateway üzerinde engellenmesi sağlanabilir.
• Blocked IP List ile bir API'ın belirli IP'ler üzerinden tüketilememesi sağlanabilir.
• Gateway üzerinde bulunan monitoring tool'ları ile (Uptime Monitor, Anomally Detector, Alert, vb..) anlık olağan dışı trafik artışı durumunda içerisindeki action yapılarını kullanarak mail gönderimi, database'e ve içinde bulundurduğu farklı yapılara log yazma gibi işlemleri gerçekleştirmesi sağlanabilir.

Bu kontroller sayesinde kötü niyetli veya hatalı istemciler kaynakları tüketemeden durdurulur ve Backend servisleri yalnızca işlenmesi gereken geçerli isteklerle ilgilenir.

#5 Kırık İşlev Seviyesinde Yetkilendirme (Broken Function Level Authorization - BFLA)

Broken Function Level Authorization (BFLA), kullanıcıların yalnızca yetkili oldukları API fonksiyonlarına erişebilmesi gerekirken, yetkilendirme kontrollerinin eksik veya hatalı uygulanması sonucunda ortaya çıkan bir güvenlik zafiyetidir.

Bu zafiyet genellikle istemci tarafındaki yetkilendirme kontrollerine güvenilmesi veya Backend servislerinde gerekli rol doğrulamalarının yapılmaması nedeniyle oluşur. Kullanıcı arayüzünde (UI) belirli işlemler gizlenmiş olsa bile, saldırgan ilgili API uç noktasını doğrudan çağırarak normal şartlarda erişememesi gereken fonksiyonları çalıştırabilir.

Örneğin normal bir kullanıcı;

• Yönetici paneline ait kullanıcı silme işlemini,
• Başka kullanıcıların hesaplarını güncelleyen bir API'yi,
• Sistem ayarlarını değiştiren yönetim servislerini,
• Sadece belirli roller tarafından kullanılabilen raporlama veya yönetim fonksiyonlarını,

doğrudan HTTP isteği göndererek çalıştırmayı deneyebilir.

Bu tür zafiyetler, yalnızca veri sızıntısına değil, aynı zamanda kritik sistem fonksiyonlarının kötüye kullanılmasına ve uygulamanın tamamen ele geçirilmesine kadar uzanabilecek ciddi güvenlik riskleri oluşturabilir.

API Gateway Bu Riski Nasıl Azaltır?

• Credential Management: Kimlik doğrulama (Authentication) işlemi API Gateway üzerinde gerçekleştiriliyorsa; JWT, OAuth2, API Key veya diğer kimlik doğrulama mekanizmaları merkezi olarak yönetilebilir. Böylece yalnızca kimliği doğrulanmış istemcilerin merkezi bir noktadan (API Gateway'den) API'lere erişip erişmemesine karar verilebilir.

• Disallowed Methods: Belirli HTTP metodlarının (POST, PUT, PATCH, DELETE vb.) istemciler tarafından kullanılmasına izin verilmeyebilir. Örneğin yalnızca veri görüntüleme amacıyla sunulan bir API'de GET metoduna izin verilirken, veri değiştiren tüm metodlar Gateway seviyesinde engellenebilir. API tanımı içerisinde API Spec'de bulunan ancak istemciler tarafından istek atılması istenmeyen endpointler devre dışı bırakılabilir.

• API'ın Gateway Üzerindeki Tanımı: API Gateway olarak profesyonel ve doğru bir çözüm kullanılıyorsa ilgili API'ın Gateway üzerinde tanımlanması adımında hangi HTTP methodları ile, hangi HTTP header'ları ve hangi HOST değerleri ile istekleri kabul edeceğini belirtip bu tanım dışında kalan isteklerin Gateway üzerinde API tanımına bile ulaşmadan isteğin bloklanması sağlanabilir.

• API Proxy Yönetimi: REST servislerinde dış dünyaya açılması istenmeyen endpoint'ler API Proxy tanımına hiç eklenmeyerek veya mevcut tanımdan kaldırılarak erişime tamamen kapatılabilir. Böylece Backend servisinde ilgili endpoint varlığını sürdürse bile Gateway üzerinden erişilemeyeceği için saldırı yüzeyi önemli ölçüde azaltılmış olur.

• Merkezi Politika Yönetimi: Aynı yetkilendirme kurallarının tüm API'lerde tutarlı şekilde uygulanması sağlanır ve farklı servislerde oluşabilecek yapılandırma hatalarının önüne geçilir.

• API Trafik Loglama ve İzleme: Yetkisiz erişim girişimleri merkezi olarak kayıt altına alınabilir ve güvenlik ekipleri tarafından analiz edilerek olası saldırılar erken aşamada tespit edilebilir.

#6 İş Mantığı Saldırılarına Karşı Sınırsız Erişim (Unrestricted Access to Sensitive Business Flows)

Her güvenlik zafiyeti teknik bir yazılım hatasından kaynaklanmaz. Bazı saldırılar, uygulamanın tamamen doğru çalışan iş süreçlerinin (Business Flow) kötüye kullanılmasıyla gerçekleştirilir. OWASP API Security Top 10 listesindeki Unrestricted Access to Sensitive Business Flows maddesi de tam olarak bu durumu ifade eder.

Örneğin bir e-ticaret uygulamasında;

• Sipariş oluşturma
• Ürün satın alma
• Stok sorgulama
• Şifre sıfırlama
• SMS doğrulama kodu gönderme

gibi işlemler tamamen meşru iş akışlarıdır.

Normal şartlarda bir kullanıcı bu işlemleri belirli aralıklarla gerçekleştirir. Ancak saldırganlar bu iş akışlarını otomatikleştirerek çok kısa süre içerisinde binlerce kez çalıştırabilir.

Hassas iş akışlarının, botlar tarafından otomatikleştirilerek saniyeler içinde manipüle edilmesi büyük zarar verir. API'ların mekanik/otomatize edilmiş bu tarz kötü niyetli insan dışı davranışları tespit edecek hız limitleri, CAPTCHA veya davranışsal analiz mekanizmalarıyla korunması gerekir.

API Gateway Bu Riski Nasıl Azaltır?

API Gateway iş kurallarını bilmediği için bu zafiyeti tek başına tamamen engelleyemez. Ancak iş akışlarının otomatik olarak kötüye kullanılmasını zorlaştıran birçok güvenlik politikasını merkezi olarak uygulayabilir.

• Rate Limiting: Aynı kullanıcıdan, IP adresinden veya API anahtarından belirli bir süre içerisinde gelebilecek istek sayısı sınırlandırılabilir. Böylece binlerce otomatik isteğin Backend servislere ulaşması engellenebilir.

• Quota: Belirli bir kullanıcıya veya uygulamaya günlük, saatlik ya da aylık kullanım kotası tanımlanabilir. Böylece belirli servislerin aşırı kullanılması önlenebilir.

• Credential Management: Hassas iş akışlarına yalnızca kimliği doğrulanmış kullanıcıların erişmesine izin verilebilir. Authentication işlemi Gateway üzerinde gerçekleştiriliyorsa yetkisiz istemciler daha ilk aşamada engellenir.

• IP Filtering: Sürekli kötü niyetli trafik üreten IP adresleri engellenebilir veya yalnızca belirli IP aralıklarından gelen istemcilere erişim izni verilebilir.

• Monitoring ve Analytics: API kullanım alışkanlıkları merkezi olarak izlenebilir. Olağan dışı trafik artışları veya normal kullanıcı davranışından sapmalar erken aşamada tespit edilerek gerekli önlemler alınabilir.

#7 Sunucu Tarafı İstek Sahteciliği (Server-Side Request Forgery - SSRF)

En basit tanımıyla SSRF; saldırganın, hedef sunucuyu bir "vekil" (proxy) gibi kullanarak normalde erişemeyeceği yerlere istek atmasını sağlamasıdır.

Normal şartlarda dış dünyaya kapalı olan, sadece şirket içindeki sunucuların birbiriyle konuşabildiği güvenli bir iç ağ (internal network) düşün. Bir saldırgan dışarıdan bu iç ağdaki verilere (örneğin AWS metadata servislerine veya yerel bir veri tabanına) doğrudan erişemez.

Ancak, dışarıya açık olan API sunucusu kullanıcıdan aldığı bir URL'e gitmeye programlanmışsa, saldırgan parametreye http://localhost:8080/admin veya http://10.10.25.210/ (bulut servislerinde hassas verilerin olduğu metadata adresi) yazar. API sunucusu bu isteği "kendi içinden" yaptığı için, iç ağdaki korumalar (güvenlik duvarları) bunu güvenli kabul eder ve saldırganın normalde göremeyeceği verileri ona altın tepside sunar.

API Gateway Bu Riski Nasıl Azaltır?

API Gateway çözümlerinin sunduğu hazır güvenlik politikaları (policies) ve gelişmiş script motorları sayesinde, bu filtreleme adımları backend koduna dokunmadan doğrudan gateway arayüzü üzerinden konfigüre edilebilir. Bu riski azaltmak için uygulanabilecek temel gateway mekanizmaları şunlardır:

• Doğrulama Politikaları (Validation Policies): Saldırganların file:// gibi protokollerle sunucu içi dosyaları okumasını engellemek için gateway üzerinde girdi doğrulaması tanımlanır. Gelen URL parametrelerinin sadece http:// veya https:// ile başlamasını zorunlu kılan kurallarla tehlikeli şemalar daha ağın girişinde elenir.

• Scripting Politikaları (Örn. Groovy/Javascript ile Dinamik Kontrol): İstek içeriği veya query parametreleri bir betik (script) motoru vasıtasıyla dinamik olarak parse edilebilir. URL içerisinde localhost, 127.0.0.1 veya 10.10.25.210 gibi kara listeye alınmış iç ağ adresleri tespit edildiği anda istek backend'e iletilmeden 403 Forbidden gibi bir hata koduyla sonlandırılır.

• IP Filtering: API Gateway, backend servislerle dış dünya arasında bir izolasyon katmanı oluşturur. Gateway üzerindeki IP filtreleme politikalarıyla, dışarıdan gelen bir kullanıcının doğrudan iç ağ IP bloklarına veya yönetim panellerine yönelik istek yapması mimari olarak engellenir.

• Rate Limiting : Bir saldırgan SSRF açığı bulduğunda, iç ağdaki diğer gizli servisleri keşfetmek için arka arkaya binlerce istek atarak iç ağ port taraması (port scanning) yapar. Gateway üzerinde aktif edilecek hız sınırlandırma kuralları, saldırganın bu taramayı yapmasını fiziksel olarak imkansız hale getirir.

• Logging & Monitoring: Parametre içeren tüm dış ve iç yönlü isteklerin Gateway üzerinden merkezi olarak loglanması sağlanır. Olağan dışı hedef adreslere giden veya anomali tespit eden gateway araçları sayesinde trafik hareketleri sistem panellerinden izlenebilir ve ilgili araçların ön tanımlı işlemleri anomali yakalanması durumunda tetiklenebilir.

#8 Güvenlik Yanlış Yapılandırması (Security Misconfiguration)

Security Misconfiguration, API ekosisteminde kullanılan sunucuların, ağ bileşenlerinin, uygulama çerçevelerinin (Framework), API Gateway'in veya Backend servislerinin güvenli olmayan şekilde yapılandırılması sonucunda ortaya çıkan güvenlik zafiyetlerini ifade eder.

Çoğu zaman saldırganlar karmaşık güvenlik açıklarından önce yanlış yapılandırılmış sistemleri hedef alırlar. Çünkü hatalı yapılandırmalar, herhangi bir yazılım zafiyeti bulunmasa bile yetkisiz erişime veya bilgi sızıntısına neden olabilir.

API dünyasında yaygın olarak karşılaşılan yapılandırma hatalarından bazıları şunlardır:

• Gereksiz HTTP metodlarının (PUT, DELETE, PATCH, TRACE vb.) istemcilere açık bırakılması.
• API'lerin HTTP üzerinden yayınlanması veya zayıf TLS yapılandırmalarının kullanılması.
• Varsayılan kullanıcı hesapları ve parolaların değiştirilmemesi.
• Ayrıntılı hata mesajlarının (Stack Trace) istemcilere döndürülmesi.
• Geliştirme veya test amaçlı endpoint'lerin üretim ortamında açık bırakılması.
• Gereksiz HTTP Header bilgilerinin istemciye gönderilmesi.
• Eski veya güncel olmayan güvenlik politikalarının kullanılmaya devam edilmesi.

API Gateway Bu Riski Nasıl Azaltır?

API Gateway, tüm API trafiğinin geçtiği merkezi nokta olduğundan güvenlik politikalarının standart ve tutarlı şekilde uygulanmasını sağlar. Böylece farklı servislerde oluşabilecek yapılandırma farklılıkları önemli ölçüde azaltılabilir.

• Credential Management: Kimlik doğrulama Gateway üzerinde gerçekleştiriliyorsa, tüm API'lerde ortak Authentication politikaları uygulanabilir ve yanlış yapılandırılmış kimlik doğrulama mekanizmalarının önüne geçilebilir.
• TLS Zorunluluğu (HTTPS Enforcement): API trafiğinin yalnızca TLS üzerinden gerçekleştirilmesi sağlanarak verilerin güvenli şekilde iletilmesi garanti altına alınabilir.
• Business Rule Politikaları: Belirli Header'ların zorunlu olması, belirli içerik tiplerinin kabul edilmesi veya uygulamaya özel güvenlik kurallarının merkezi olarak uygulanması sağlanabilir.
• Header Manipülasyonu: Sunucu hakkında bilgi velen gereksiz HTTP Header'ları kaldırılabilir, güvenlik Header'ları eklenebilir ve istemciye dönen bilgiler kontrol altına alınabilir.
• API Proxy Yönetimi: Üretim ortamında kullanılmayacak servisler veya endpoint'ler API Proxy tanımlarına eklenmeyerek ya da devre dışı bırakılarak dış dünyaya tamamen kapatılabilir. Böylece gereksiz saldırı yüzeyi oluşturulmasının önüne geçilir.
• Merkezi Politika Yönetimi: Kimlik doğrulama, yetkilendirme, hız sınırlama ve diğer güvenlik politikaları tüm API'lerde standart şekilde uygulanabilir.
• Monitoring ve Audit Log: Yapılandırma değişiklikleri ve güvenlik ihlalleri merkezi olarak izlenebilir, olası yanlış yapılandırmalar daha hızlı tespit edilebilir.

#9 Hatalı Envanter Yönetimi (Improper Inventory Management)

Modern yazılım mimarilerinde API'ler sürekli olarak geliştirilir, yeni sürümleri yayınlanır ve zaman içerisinde kullanımdan kaldırılır. Bu yaşam döngüsü doğru yönetilmediğinde, kurum içerisinde unutulmuş, dokümante edilmemiş veya artık kullanılmaması gereken API'ler üretim ortamında erişilebilir durumda kalabilir.

OWASP bu durumu Improper Inventory Management olarak tanımlar.

Envanteri doğru yönetilemeyen API'ler genellikle;

• Eski API sürümlerini (v1, v2 vb.) üretim ortamında erişilebilir bırakır.
• Test veya geliştirme amacıyla oluşturulan endpoint'leri yanlışlıkla yayınlar.
• Kullanılmayan servisleri yayından kaldırmaz.
• Güncel dokümantasyona sahip olmayan API'ler barındırır.
• Hangi API'nin kim tarafından kullanıldığını takip edemez.

Bu durum "Shadow API" (kurumun farkında olmadığı API'ler) ve "Zombie API" (artık kullanılmayan ancak hâlâ erişilebilir olan API'ler) gibi ciddi güvenlik risklerinin oluşmasına neden olur. Çünkü bu API'ler çoğu zaman güncel güvenlik politikalarından, yamalardan ve yetkilendirme mekanizmalarından mahrum kalır.

API Gateway Bu Riski Nasıl Azaltır?

• API Proxy Management: Yalnızca Gateway üzerinde tanımlanan API Proxy'leri dış dünyaya açılır. Yayınlanmayan servisler istemciler tarafından doğrudan erişilemez.
• Merkezi API Yayınlama: API'lerin yayınlanması, güncellenmesi ve erişime kapatılması merkezi olarak yönetilebilir. Böylece üretim ortamında unutulmuş servislerin bulunma ihtimali önemli ölçüde azalır.
• API Versioning: Aynı servisin farklı sürümleri kontrollü şekilde yönetilebilir. Eski sürümler belirli bir geçiş sürecinin ardından erişime kapatılarak güncel olmayan API'lerin kullanılmasının önüne geçilebilir.
• Route Management: İstemcilerin yalnızca tanımlanmış rotalar üzerinden Backend servislerine erişmesine izin verilir. Tanımlanmamış endpoint'ler Gateway tarafından yönlendirilmez.
• Monitoring ve Analytics: Hangi API'lerin aktif olarak kullanıldığı, hangi sürümlerin artık kullanılmadığı ve erişim istatistikleri merkezi olarak izlenebilir. Bu sayede kullanılmayan API'ler tespit edilerek güvenli şekilde devre dışı bırakılabilir.
• Audit Log: API yayınlama, güncelleme ve kaldırma işlemleri kayıt altına alınabilir. Böylece yapılan değişiklikler izlenebilir ve geriye dönük olarak denetlenebilir.

Bu merkezi yönetim yaklaşımı sayesinde API envanteri sürekli güncel tutulabilir ve istemcilerin yalnızca kurum tarafından desteklenen API'lere erişmesi sağlanabilir.

API Gateway, kurumun dış dünyaya açtığı tüm API'ler için ilgili API'nin tanımını kendi içerisinde değiştirir ve back-end'in sürümü değiştikçe spec dosyası re-parse edilerek ilgili API tanımlaması da güncellenmiş olur. Böylece hangi servislerin erişime açık olduğu tek bir platform üzerinden yönetilebilir ve kontrol altında tutulabilir.

#10 API'ların Güvensiz Tüketimi (Unsafe Consumption of APIs)

Modern uygulamalar yalnızca kendi API'lerini sunmakla kalmaz, aynı zamanda ödeme sistemleri, kimlik doğrulama servisleri, kargo firmaları, SMS sağlayıcıları, bankalar ve diğer üçüncü taraf servislerle sürekli iletişim kurar. Bu nedenle uygulamalar yalnızca API sağlayıcısı (Provider) değil, aynı zamanda bir API tüketicisidir (Consumer).

Birçok sistem, üçüncü taraf API'lerden dönen verilerin her zaman doğru ve güvenilir olduğunu varsayar. Ancak bu varsayım oldukça tehlikelidir. Harici servislerden dönen veriler beklenmeyen içerikler barındırabilir, manipüle edilmiş olabilir veya güvenliği ihlal edilmiş bir servis tarafından üretiliyor olabilir.

Üçüncü taraf API'lerle iletişim kurarken en önemli prensip, dış sistemlerden gelen verilere koşulsuz güvenmemektir. API Gateway, uygulama ile harici servisler arasında merkezi bir güvenlik katmanı oluşturarak bu entegrasyonların daha kontrollü ve güvenli şekilde yönetilmesine yardımcı olur.

Örneğin;

• Beklenmeyen veri tipleri döndürülebilir.
• Beklenenden çok daha büyük veri paketleri gönderilebilir.
• Hatalı veya eksik JSON/XML içerikleri üretilebilir.
• Güvenilmeyen bir servise yanlışlıkla istek gönderilebilir.
• Güvenliği zayıf veya güncel olmayan üçüncü taraf API'leri kullanılabilir.

Bu durum yalnızca veri bütünlüğünü değil, uygulamanın güvenliğini ve sürekliliğini de doğrudan etkileyebilir.

API Gateway Bu Riski Nasıl Azaltır?

• JSON/XML Schema Validation: Harici servislerden dönen JSON veya XML içeriklerinin beklenen veri şemasına uygunluğu doğrulanabilir. Beklenmeyen alanlar, eksik zorunlu bilgiler veya hatalı veri yapıları tespit edilerek uygulamaya ulaşmadan engellenebilir.

• İş Kuralı Doğrulama Mekanizmaları: Dış API'lerden dönen veriler üzerinde uygulamaya özel doğrulamalar gerçekleştirilebilir. Örneğin belirli alanların boş olmaması, beklenen değer aralıklarında bulunması veya belirli iş kurallarını sağlaması kontrol edilebilir. Gerekirse güvenilmeyen veriler dönüştürülebilir veya tamamen reddedilebilir.

Sonuç ve API Güvenliği Yaklaşımı

OWASP API Güvenliği Top 10 listesinin açıkça ortaya koyduğu üzere, geleneksel ağ güvenliği çözümleri (WAF, Firewall vb.) API katmanındaki karmaşık iş mantığı ve yetkilendirme hatalarını tek başına engellemekte yetersiz kalmaktadır.

Güvenli Bir API Ekosistemi İnşa Etmek

Güvenli bir API ekosistemi inşa etmek aşağıdaki unsurları zorunlu kılmaktadır:

• Merkezi Kimlik Doğrulama ve Yetkilendirme: Her uç noktada merkezi olarak yönetilmesi
• Sıkı Girdi Doğrulaması: Input validation'ın katı tutulması
• Güncel Envanter: Tüm API envanterinin güncel tutulması
• Erken Güvenlik Testleri: Güvenlik testlerinin yazılım geliştirme yaşam döngüsünün (SDLC) en erken aşamalarına dahil edilmesi

Yalnızca bu kapsamlı ve proaktif yaklaşım sayesinde API'ler gerçekten güvenli hale getirilebilir.