API Güvenliği En İyi Uygulamaları: Kimlik Doğrulama, Yetkilendirme ve Hız Sınırlama

API'ler modern iş platformlarının bağ dokusudur. ERP'niz e-Ticaret mağazanızla API'ler aracılığıyla iletişim kurar. Ödeme ağ geçidiniz işlemleri API'ler aracılığıyla işler. Mobil uygulamanız verileri API'ler aracılığıyla alır. Saldırganlar da şunu biliyor: Gartner, 2026 yılına kadar API'lerin kurumsal web uygulamaları için geleneksel web arayüzlerini geride bırakarak en sık görülen saldırı vektörü olacağını öngörüyor.

OWASP API Güvenliği İlk 10, en yaygın API güvenlik açıklarının sıra dışı sıfır günler olmadığını, bunların temel kimlik doğrulama hataları, bozuk yetkilendirme ve aşırı veri açığa çıkması olduğunu ortaya koyuyor. Bunlar karmaşık saldırılardan ziyade, yetersiz güvenlik mimarisinden kaynaklanan önlenebilir kusurlardır.

Önemli Çıkarımlar

• PKCE'li OAuth2, API kimlik doğrulaması için geçerli standarttır; Üretim sistemleri için API anahtarları tek başına yetersizdir
• Bozuk Nesne Düzeyinde Yetkilendirme (BOLA), bir numaralı API güvenlik açığıdır -- her uç noktanın kaynak sahipliğini doğrulaması gerekir
• Hız sınırlama, yalnızca performans optimizasyonu değil, bir güvenlik kontrolüdür --- kimlik bilgilerinin doldurulmasını, numaralandırılmasını ve DoS'yi önler
• API sınırındaki giriş doğrulaması, enjeksiyon, taşma ve iş mantığı saldırılarını veritabanınıza ulaşmadan önler

---

Kimlik Doğrulama: Kimliğin Kanıtlanması

Kimlik doğrulama "bu isteği kim yapıyor?" sorusunu yanıtlar. API'ler için yanıtın kriptografik olarak doğrulanabilir, tekrar saldırılara karşı dayanıklı ve dağıtılmış sistemlerde ölçeklenebilir olması gerekir.

Kimlik Doğrulama Yöntemi Karşılaştırması

OAuth2 ve OIDC En İyi Uygulamaları

OpenID Connect (OIDC) özellikli OAuth2, modern uygulamalarda API kimlik doğrulaması standardıdır. Temel uygulama uygulamaları:

**Tek sayfalı uygulamalar ve mobil uygulamalar dahil tüm istemci türleri için PKCE ile Yetki Kodu akışını kullanın. Örtülü akış, tarayıcı geçmişindeki ve yönlendiren başlıklarındaki belirteçlerin açığa çıkması nedeniyle kullanımdan kaldırıldı.

Kısa ömürlü erişim belirteçleri. Erişim belirteçlerinin süresinin 15-60 dakika içinde dolması gerekir. Yeniden kimlik doğrulaması gerekmeden yeni erişim belirteçleri elde etmek için yenileme belirteçlerini (güvenli bir şekilde saklanır, kullanım sırasında döndürülür) kullanın.

Belirteç depolama. Belirteçleri hiçbir zaman localStorage veya sessionStorage'da saklamayın (XSS'e karşı savunmasızdır). HttpOnly çerezlerini Secure ve SameSite nitelikleriyle kullanın. Belirteçleri doğrudan kullanması gereken SPA'lar için, bunları yalnızca bellekte tutun ve sayfa yenilendiğinde oturum kaybının telafisini kabul edin.

Belirteçleri kapsamlı bir şekilde doğrulayın. Her API isteğinin, belirtecin imzasını, son kullanma tarihini, vereni, hedef kitlesini ve kapsamını doğrulaması gerekir. JWT'nin kodunu çözüp içeriğine güvenmeyin.

Jeton bağlama. Mümkün olduğunda, jeton hırsızlığını ve tekrar oynatılmasını önlemek için, jetonları DPoP (Sahip Olma Kanıtı Gösterme) başlıklarını kullanarak talep eden müşteriye bağlayın.

JWT Güvenlik Konuları

JWT'ler, API'ler için en yaygın token formatıdır ancak belirli riskler taşırlar:

• Asla none algoritmasını kullanmayın. alg başlığını her zaman beklenen algoritmaların beyaz listesine göre doğrulayın.
• Genel kullanıma açık API'ler için simetrik (HS256) yerine asimetrik algoritmaları (RS256, ES256) tercih edin. Asimetrik anahtarlar, imzalama anahtarını paylaşmadan jeton doğrulamaya olanak tanır.
• Standart talepleri dahil edin: iss (veren), aud (kitle), exp (son kullanma tarihi), iat (verilme tarihi), sub (konu), jti (iptal için benzersiz kimlik).
• Yük yüklerini küçük tutun. JWT'ler bir veritabanı değildir. Yalnızca yetkilendirme kararları için gereken talepleri ekleyin. Gerektiğinde kullanıcı bilgisi uç noktalarından ek veriler alın.
• Belirteç iptalini uygulayın. Hesapların güvenliği ihlal edildiğinde anında iptal için bir belirteç engelleme listesiyle (Redis veya benzeri) birlikte kısa süre sonu süreleri kullanın.

---

Yetkilendirme: Erişim Kontrolünü Zorunlu Hale Getirme

Kimlik doğrulama, isteği kimin yaptığını size bildirir. Yetkilendirme size ne yapmalarına izin verildiğini söyler. OWASP API Top 10, Kırık Nesne Düzeyinde Yetkilendirmeyi (BOLA) bir numaralı API güvenlik açığı olarak listeliyor çünkü hem en yaygın hem de en etkili güvenlik açığıdır.

RBAC ve ABAC

Rol Tabanlı Erişim Denetimi (RBAC) rollere izinler atar ve rollere kullanıcılar atanır. Uygulaması ve gerekçesi basittir.

Öznitelik Tabanlı Erişim Denetimi (ABAC) politikaları kullanıcının, kaynağın, eylemin ve ortamın özniteliklerine göre değerlendirir. Daha karmaşık kuralları destekler ancak denetlenmesi daha zordur.

ERP ve e-Ticaret sistemleri de dahil olmak üzere çoğu iş platformu için RBAC, kaynak sahipliği kontrolleriyle birleştirildiğinde yeterlidir. Yetkilendirme kurallarınız zaman, konum, veri sınıflandırması veya dinamik organizasyonel hiyerarşiler gibi bağlamsal faktörlere bağlı olduğunda ABAC'ı düşünün.

BOLA'nın önlenmesi

Bozuk Nesne Düzeyinde Yetkilendirme, bir API'nin, kaynak tanımlayıcılarını değiştirerek kullanıcıların diğer kullanıcılara ait kaynaklara erişmesine veya bunları değiştirmesine izin vermesi durumunda ortaya çıkar. Örneğin, /api/orders/12345 öğesini /api/orders/12346 olarak değiştirmek başka bir kullanıcının siparişini ortaya çıkarmamalıdır.

Önleme kuralları:

1. Her uç nokta kaynak sahipliğini doğrulamalıdır. Hiçbir zaman yalnızca kimlik doğrulamasına güvenmeyin. Kullanıcının kimliğini doğruladıktan sonra, talep edilen belirli kaynağa erişimleri olduğunu doğrulayın.
2. Dolaylı referanslar kullanın. Sıralı veritabanı kimliklerini açığa çıkarmak yerine UUID'leri veya kullanıcı kapsamlı referans numaralarını kullanın.
3. Veri katmanında uygulayın. Yalnızca denetleyici düzeyinde değil, her veritabanı sorgusuna sahiplik filtreleri (ör. WHERE organization_id = ?) ekleyin. Bu, ECOSIRE'ın platform mimarisi boyunca kullanılan çoklu kiracılık modelidir.
4. Otomatik test. CI/CD ardışık düzeninize yetkilendirme atlama testlerini ekleyin. Her uç nokta için A Kullanıcısının B Kullanıcısının kaynaklarına erişemediğini test edin.

---

Hız Sınırlama ve Azaltma

Hız sınırlama, yalnızca aşırı yüklemeyi önleyen bir performans optimizasyonu değil, kötüye kullanımı önleyen bir güvenlik kontrolüdür. Saldırganlar, hız sınırlaması olmadan, saniyede binlerce denemeyle kimlik bilgisi doldurma işlemi gerçekleştirebilir, geçerli hesapları sıralayabilir, tüm ürün kataloğunuzu silebilir veya API kotalarınızı yukarı akış sağlayıcılarıyla tüketebilir.

Hız Sınırlama Stratejileri

Uç Nokta Türüne Göre Hız Sınırlama

Farklı uç noktalar farklı tehdit profilleriyle karşı karşıyadır ve farklı sınırlar gerektirir:

• Kimlik doğrulama uç noktaları (oturum açma, belirteç değişimi): IP başına dakikada 5-10 istek. Düşük limitler, kimlik bilgisi doldurmayı ve kaba kuvveti önler.
• Şifre sıfırlama / hesap kurtarma: Hesap başına saatte 3-5 istek. Hesap numaralandırmasını ve kötüye kullanımını önler.
• Veri okuma uç noktaları: Kullanıcı başına dakikada 100-1000 istek. Normal kullanıma izin verirken kazımayı önler.
• Veri yazma uç noktaları: Kullanıcı başına dakikada 30-60 istek. Otomatik kötüye kullanımı ve spam'i önler.
• Genel arama uç noktaları: IP başına dakikada 20-60 istek. Rekabetçi kazımayı önler.
• Web kancası alıcıları: Hız sınırlaması yerine imzaları doğrulayın ancak beklenen hacmi aşan istekleri bırakın.

Hız Sınırlarının Uygulanması

İstemcilerin kendi kendilerini düzenleyebilmeleri için uygun HTTP durum kodlarını ve başlıklarını döndürün:

• 429 Çok Fazla İstek limit aşıldığında
• Limit sıfırlanana kadar geçen saniye sayısını içeren Retry-Aft başlığı
• İzin verilen toplam istekleri gösteren X-RateLimit-Limit başlığı
• X-RateLimit-Remaining başlığı, pencerede bırakılan istekleri gösterir
• Pencere sıfırlandığında UTC zaman damgasını içeren X-RateLimit-Reset başlığı

Saldırganların sınırları atlamak için örnekleri örnekler arasında dağıtmasını önlemek için örnek başına sınırlamalar yerine merkezi bir hız sınırlama hizmeti (Redis destekli) kullanın.

---

Giriş Doğrulaması

API sınırındaki giriş doğrulama, ekleme saldırılarına, arabellek taşmalarına ve iş mantığının kötüye kullanılmasına karşı ilk savunma hattınızdır. API'nize giren her veri parçasının tür, biçim, uzunluk, aralık ve iş kuralları açısından doğrulanması gerekir.

OWASP API Güvenliği İlk 10

OWASP API Güvenliği İlk 10 (2023 baskısı), her API'nin ele alması gereken kritik riskleri tanımlar:

Doğrulama İçin En İyi Uygulamalar

Şema doğrulama. İstek şemalarını tanımlayın (JSON Schema, Zod veya OpenAPI spesifikasyonunu kullanarak) ve uygun olmayan tüm istekleri reddedin. Bu, hatalı biçimlendirilmiş verileri iş mantığına ulaşmadan yakalar.

Parametreli sorgular. Kullanıcı girişini asla SQL, NoSQL veya LDAP sorgularında birleştirmeyin. Kaçmayı otomatik olarak gerçekleştiren parametreli sorguları veya ORM yöntemlerini kullanın. Bu, tüm iş platformları için bir kritik güvenlik kuralıdır.

İçerik türü zorunluluğu. Yalnızca beklenen İçerik Türü üstbilgilerini kabul edin. JSON'u bekleyen bir API, ayrıştırıcı tabanlı saldırıları önlemek için XML'i, form verilerini ve diğer içerik türlerini reddetmelidir.

Yanıt filtreleme. Hiçbir zaman tam veritabanı kayıtlarını istemciye iade etmeyin. Her yanıta hangi alanların dahil edildiğini açıkça tanımlamak için DTO'ları (Veri Aktarım Nesneleri) kullanın. Parola karmaları, dahili kimlikler ve denetim meta verileri gibi dahili alanlar hiçbir zaman API yanıtlarında görünmemelidir.

Hata işleme. İstemcilere genel hata iletilerini döndürün. Yığın izlerini, veritabanı hatalarını veya dahili sistem ayrıntılarını asla açığa çıkarmayın. Hata ayıklama için ayrıntılı hataları sunucu tarafında günlüğe kaydedin.

---

API Güvenlik Mimarisi Modelleri

API Ağ Geçidi Kalıbı

Bir API ağ geçidi, tüm arka uç hizmetlerinin önünde bulunur ve kesişen güvenlik endişelerini merkezileştirir:

• Kimlik Doğrulama --- İstekler arka uç hizmetlerine ulaşmadan önce belirteçleri doğrular
• Hız sınırlama --- Ağ geçidi düzeyinde sınırlamaları zorunlu kılar
• İstek/yanıt dönüşümü --- Hassas başlıkları çıkarır, güvenlik başlıklarını ekler
• Günlüğe kaydetme ve izleme --- Güvenlik analizi için tüm API trafiğini yakalar
• WAF entegrasyonu --- Bilinen saldırı modellerini engeller (SQL enjeksiyonu, XSS verileri)

Popüler API ağ geçitleri arasında Kong, AWS API Gateway, Azure API Management ve Traefik yer alır.

Hizmetten Hizmete Kimlik Doğrulaması

Mikro hizmetler arasındaki dahili API'ler de kimlik doğrulama gerektirir. Seçenekler şunları içerir:

• Karşılıklı TLS (mTLS) --- Hem istemci hem de sunucu sertifikaları sunar. Güçlü ama operasyonel olarak karmaşık.
• Hizmet belirteçleri --- Hizmetler, önceden paylaşılan belirteçlerle kimlik doğrulaması yapar. Basit ama güvenli dağıtım gerektirir.
• Servis ağı --- Istio veya Linkerd, Kubernetes'teki hizmetler arasında mTLS'yi otomatik olarak yönetir.
• OAuth2 İstemci Kimlik Bilgileri --- Hizmetler, erişim belirteçlerini elde etmek için istemci kimliğini ve sırrını kullanarak kimlik doğrulaması yapar.

Sıfır güven mimarisi için, bir ihlal sonrasında yanal hareketi önlemek için hizmetten hizmete kimlik doğrulama çok önemlidir.

---

İzleme ve Olay Tespiti

API güvenliği izleme, hem teknik sinyalleri (başarısız kimlik doğrulama girişimleri, olağandışı istek modelleri) hem de iş sinyallerini (anormal işlem miktarları, toplu veri erişimi) yakalamalıdır.

Kritik API Güvenlik Sinyalleri

• Kimlik doğrulama hataları --- Tek bir IP'den başarısız oturum açmalarda veya tek bir hesabı hedeflemede ani artış
• Yetkilendirme hataları --- Kullanıcıların yetkisiz kaynaklara erişmeye çalıştığını gösteren 403 yanıt
• Oran sınırı ihlalleri --- Aynı kaynaktan sürekli 429 yanıt alındı
• Olağandışı veri hacimleri --- Veri sızmasını öneren toplu okuma işlemleri
• Parametre kurcalama --- Sıralı kimlik numaralandırma, negatif değerler, sınır testi
• Coğrafi anormallikler --- Beklenmedik bölgelerden veya imkansız seyahat şekillerinden API çağrıları

Bu sinyalleri gerçek zamanlı olarak ortaya çıkaran kontrol panelleri oluşturun. Diğer güvenlik olaylarıyla korelasyon için SIEM'inizle entegre olun. Yüksek güvenliğe sahip tehditler için otomatik yanıtlar tanımlayın: Başarısız kimlik doğrulama eşiklerini aşan IP'leri engelleyin, imkansız seyahat sergileyen hesapları geçici olarak devre dışı bırakın ve toplu veri erişim modelleriyle ilgili uyarı verin.

---

Sıkça Sorulan Sorular

API anahtarlarını mı yoksa OAuth2 belirteçlerini mi kullanmalıyım?

Kullanıcıya yönelik uygulamalara veya üçüncü taraf entegrasyonlarına hizmet eden tüm API'ler için OAuth2 belirteçlerini kullanın. API anahtarları yalnızca her iki uç noktanın da kontrolünüz altında olduğu sunucular arası iletişim için kabul edilebilir ve bu durumda bile HMAC imzalı istekler daha güçlü güvenlik sağlar. Herkese açık uç noktalar için asla tek kimlik doğrulama olarak API anahtarlarını kullanmayın.

API sürüm oluşturma işlemini güvenli bir şekilde nasıl halledebilirim?

Netlik ve keşfedilebilirlik için URL tabanlı sürüm oluşturmayı (ör. /api/v2/orders) kullanın. Bir sürümü kullanımdan kaldırırken, bir kullanımdan kaldırılma tarihi belirleyin, bunu tüketicilere bildirin ve kullanımı izleyin. Kullanımdan kaldırılan sürümler tamamen kullanımdan kaldırılıncaya kadar güvenlik yamalarını uygulamaya devam edin. Hiçbir zaman yama yapılmamış eski API sürümlerini çalışır durumda bırakmayın; bunlar kolay hedefler haline gelir.

Bir işletme API'si için hangi hız sınırlarını ayarlamalıyım?

İhtiyatlı başlayın ve yasal kullanım verilerine göre artırın. Kimlik doğrulama uç noktaları için IP başına dakikada 5-10 istek standarttır. Veri uç noktaları için, kimliği doğrulanmış kullanıcı başına dakikada 100-500 istek çoğu iş kullanım durumunu kapsar. Çok kısıtlayıcı sınırları belirlemek için 429 yanıtı izleyin ve aşırı cömert sınırları belirlemek için kötüye kullanım kalıplarını izleyin.

Web kancalarını üçüncü taraf hizmetlerden nasıl koruyabilirim?

Paylaşılan bir sırla HMAC-SHA256'yı kullanarak web kancası imzalarını doğrulayın. Tekrarlama saldırılarını önlemek için zaman damgasını doğrulayın (5 dakikadan eski etkinlikleri reddedin). Zaman aşımına dayalı hizmet reddini önlemek için web kancalarını eşzamansız olarak işleyin. Denetim amacıyla tüm webhook olaylarını günlüğe kaydedin. İşlemeden önce yük şemasını doğrulayın.

---

Sırada Ne Var

API güvenliği, geliştirmenin sonunda eklediğiniz bir özellik değildir; ilk uç noktadan itibaren mevcut olması gereken bir tasarım ilkesidir. Güçlü kimlik doğrulamayla (OAuth2/OIDC) başlayın, her kaynak erişim noktasında yetkilendirmeyi zorunlu kılın, tüm uç nokta türlerinde hız sınırlaması uygulayın ve API sınırınızı aşan her girişi doğrulayın.

ECOSIRE, güvenliği her API entegrasyonuna dahil eder. OpenClaw AI platformumuz varsayılan olarak HMAC imzalı istekleri, hız sınırlamayı ve SSRF korumasını uygularken, Odoo ERP entegrasyonlarımız rol tabanlı erişim kontrolüyle OAuth2/OIDC'yi kullanıyor. İş platformu API'larınızın güvenliğini sağlamak için ekibimizle iletişime geçin.

---

ECOSIRE tarafından yayınlandı --- işletmelerin Odoo ERP, Shopify eCommerce ve OpenClaw AI genelinde yapay zeka destekli çözümlerle ölçeklenmesine yardımcı oluyor.