Vebende Akademi - api-attacks
Uzmanla Konuşun
Blog
MAKALE

API Attacks — API Saldırıları: Türler, Mekanikler, Tespit ve Mitigasyon Rehberi

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~60–200 dk

API Attacks — API Saldırıları: Türler, Mekanikler, Tespit ve Mitigasyon Rehberi

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~60–200 dk

1. GİRİŞ

API'ler modern yazılım dünyasının merkezinde yer alır; mobil uygulamalardan web arayüzlerine, mikroservislerden üçüncü taraf entegrasyonlarına kadar tüm iletişim API kanalları üzerinden sağlanır. Bu yaygın kullanım, API'leri siber saldırganların birinci sınıf hedefi hâline getirmiştir. "API Attacks" başlıklı bu derin rehber, API saldırı yüzeylerini, saldırı taktiklerini, tespit ve müdahale yaklaşımlarını hem teknik hem de operasyonel bakış açısıyla ele alır.

Bu neden bugün önemli?

  • API'ler doğrudan veri ve iş mantığını açığa çıkardığı için başarılı bir saldırı doğrudan veri sızıntısı ya da finansal kayıp yaratabilir.
  • Automasyon araçları ve botnet'ler sayesinde credential stuffing, scraping ve brute‑force saldırıları büyük ölçekte yürütülüyor.
  • API ekonomisi, üçüncü taraf erişimleri ve webhook tabanlı entegrasyonlar supply‑chain risklerini beraberinde getiriyor.

Kimler için önemli?

Backend geliştiriciler, API mimarları, platform mühendisleri, güvenlik ekipleri ve ürün yöneticileri için bu rehber hayati bilgiler içerir. Ayrıca DevOps ve SRE ekipleri operasyonel önlemler ve monitoring ile ilgili kısmı faydalı bulacaktır.

Hangi problemleri çözüyor?

  • API üzerinden gerçekleşen veri sızıntılarını ve yetkisiz erişimleri azaltma
  • Bot tabanlı kötüye kullanımı tespit edip engelleme
  • İnce ayarlı rate limiting, auth/authorization ve telemetry ile hızlı müdahale yeteneği sağlama

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

  • API Attack: API endpoint'lerine yönelik kötü niyetli istekler ve manipülasyonlar (ör. yetki atlatma, veri çekme, servis kötüye kullanımı).
  • API Surface: API tarafından dışa açılan tüm endpoint'ler, parametreler, webhook'lar ve dokümantasyonun toplamı.
  • Excessive Data Exposure: API'nin gereğinden fazla bilgi döndürmesi; saldırganın az sayıda istekle çok veri elde etmesine yol açar.
  • Mass Assignment / Object Injection: İstemciden gelen veri ile server‑side model attribute'lerinin kontrolsüz doldurulması.

2.2 Sık karşılaşılan saldırı türleri (kısa)

  • Broken Object Level Authorization (BOLA / IDOR)
  • Broken Authentication ve JWT/Token tampering
  • Rate limit bypass, account enumeration, credential stuffing
  • API abuse — scraping, scraping with low‑cost proxies
  • Injection (SQL, NoSQL, Command), deserialization attacks
  • Misconfigured CORS, open redirect, exposed debug endpoints
  • Replay attacks, request forgery ve signed webhook bypass

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE SİSTEM AKIŞLARI

3.1 Tipik API mimarisi

Client → CDN/edge → API Gateway → Auth Service (IdP) → Microservices → Data Stores. Gateway, cross‑cutting concerns (auth, rate limiting, WAF) için merkezi noktadır; servisler iş mantığını uygular. Güvenlik kontrollerinin nerede uygulanacağı mimari kararların merkezidir: bazı kontroller gateway'de, bazıları ise servislerde yapılmalıdır. Kritik olan şudur: yetkilendirme kararları her zaman server‑side ve mümkünse service‑level bazda doğrulanmalıdır.

3.2 Veri akışı ve risk noktaları

  • Client tarafından gelen token'ların doğrulanması (aud/iss/exp)
  • Parametre bazlı erişim kontrolü (ownerId == userId)
  • Response shaping: gereksiz alanların (ör. internal flags, debugging info) döndürülmemesi
  • Webhook ve callback doğrulamaları: replay ve signature kontrolü

3.3 Saldırı senaryoları — örnekler

BOLA / IDOR

Endpoint: GET /orders/{orderId}. Eğer uygulama token'daki userId ile order.ownerId kontrolünü yapmıyorsa bir kullanıcı başka kullanıcıların siparişlerini görebilir. Bu, nesne seviyesinde yetkilendirme hatasıdır.

Credential stuffing & Account takeover

Sızıntı ile elde edilmiş kullanıcı/parola listeleri otomatik araçlarla API login endpoint'lerine gönderilir. Başarılı girişler saldırgan tarafından account takeover ile sonuçlanır. Korunmak için rate limiting, IP reputasyon, MFA zorunluluğu ve login attempt monitoring gereklidir.

Excessive data exposure

Kullanıcı listesi endpoint'i gereğinden fazla alan döndürüyor (email, phone, address). Sıkça kullanılan pattern: adminOnly alanlar frontend'de client‑side filtre ile gizlenir ama API aynı veriyi döndürür. Bu, attack surface'i ciddi şekilde genişletir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Büyük platform örnekleri

Stripe, Uber, Amazon, Netflix gibi büyük platformların ciddi API güvenlik yatırımları vardır. Örneğin Stripe, webhook'ları HMAC ile imzalar ve replay protection sağlar; Netflix edge katmanında rate limiting, anomaly detection ve fine‑grained telemetry uygular. Bu firmaların ortak noktası: API'leri tek bir saldırı yüzeyi olarak görmek yerine, telemetry, policy, ve automation ile sürekli olarak korumaktır.

4.2 Başarılı saldırı vakaları

Pek çok yüksek profilli ihlal API güvenlik eksiklerinden kaynaklanmıştır: exposed API keys via public repos, misconfigured cloud storage endpoints, veya broken authorization kontrolleri. Bu olayların ortak özelliği genellikle insan hatası veya otomasyon eksikliğidir.

4.3 Third‑party integrations ve supply chain riskleri

Webhooks, SDK'lar ve public APIs üzerinden çalışan üçüncü taraf entegrasyonları supply‑chain riskleri yaratır. Örneğin kötü amaçlı bir SDK veya açık API key'ler saldırgan için kolay erişim sağlayabilir. SBOM konseptinin API bileşenlerine uyarlanması, dependency visibility sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar — güçlü API güvenliğinin faydaları

  • Veri sızıntı riskinin azalması ve uyumluluk gereksinimlerinin karşılanması
  • Hizmet sürekliliğinin korunması — DoS / abuse saldırılarına karşı stabilite
  • Güvenilir üçüncü taraf entegrasyonları sayesinde iş ortaklığı fırsatları

Sınırlamalar ve zorluklar

  • Gateway merkezileştirme tek bir hata noktasına (SPOF) dönüşebilir; yüksek erişilebilirlik planı şarttır.
  • Fine‑grained authorization performans maliyetleri oluşturabilir; karar caching önemli ama dikkat gerektirir.
  • API'lerin sürekli evrilen doğası discovery ve inventory yönetimini zorlaştırır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

YaklaşımAvantajDezavantaj
API Gateway + Central PolicyMerkezi kontrol, hızla policy uygulamaSPOF ve gateway bypass riskleri
Service‑level authorizationİş mantığına yakın doğrulukTekrarlayan kod ve tutarlılık problemi
Mesh + sidecarService‑to‑service kimlik ve policy enforcementOperasyonel karmaşıklık
Serverless + managed APIOtomatik ölçek, yönetilen güvenlikProvider lock‑in ve cold start

7. EN İYİ PRATİKLER

Production kullanımı

  • Least privilege & scoped tokens: Access token'ları minimum scope ile verin; per‑service ve per‑user scopes uygulayın.
  • Short‑lived tokens & refresh rotation: Access token'ları kısa ömürlü yapın; refresh token'ları rotate edin ve blacklist mekanizması kurun.
  • Input validation & schema validation: JSON Schema/Protobuf kullanarak tüm payload'ları validate edin; strict typing injection riskini azaltır.
  • Authorization server side: Bütün yetkilendirme kontrolleri server/servis katmanında yapılmalı; client‑side kontroller yalnızca UX içindir.
  • Rate limiting & progressive challenges: Per‑user, per‑IP ve per‑API limitler; şüpheli durumda CAPTCHA veya MFA gibi zorluklar uygulayın.
  • Excessive data exposure control: Response shaping ve field‑level filtering ile sadece gereken alanları döndürün.

Performans ve operasyon

  • Decision caching: Authorization kararlarını kısa TTL ile cache edin; invalidation stratejisi kurun.
  • Distributed tracing & observability: request traces, auth failures, denied requests ve anomaly korelasyonu için telemetry toplayın.
  • Automated scanning: contract tests, fuzzing, DAST, SAST ve API posture scanning rutinleri kurun.

Güvenlik

  • Signed webhooks, replay protection, and mutual TLS for sensitive callbacks.
  • Use API keys as low‑privilege artifacts and rotate regularly; do not bake keys into client binaries.
  • Pen‑testing and red team scenarios: include BOLA/IDOR, auth bypass and mass‑scraping tests.

8. SIK YAPILAN HATALAR

  • Client‑side filtering ile sensitive fields'i gizlemek fakat API aynı veriyi döndürmeye devam etmek.
  • Gateway güvenliğini tam saymayıp servislerde authorization kontrolleri yapmamak.
  • Excessive privileges for service accounts — IAM rollback ve least privilege uygulanmaması.
  • Not monitoring for abuse patterns — scraping ve credential stuffing aktivitelerinin fark edilmemesi.
  • Hard‑coding secrets in code or public repos.

9. GELECEK TRENDLER

AI destekli attack detection ve adaptive defenses

ML modelleri normal ve anormal request pattern'larını öğrenip botnet aktivitelerini, credential stuffing ve scraping'i gerçek zamanlı tespit edebilecek; adaptive rate limiting ve dynamic challenge mekanizmaları tetiklenebilecek.

API Posture Management ve continuous discovery

API kataloglama, otomatik sözleşme tarama ve posture scoring ile organizasyonlar yüzeylerini sürekli değerlendirecek; eksik güvenlik kontrolleri ve exposed endpoints otomatik tespit edilecek.

Zero trust ve identity‑centric approaches

Service identity, workload identity ve short‑lived credentials ile zero trust ilkeleri API ekosistemine daha sıkı şekilde entegre edilecek; service mesh ve policy engines yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

  1. 1. API saldırılarını hızlıca tespit etmek için hangi metriklere bakmalıyım?

    Failed auth attempts, spike in request rate, unusual endpoint access patterns, increased 4xx/5xx rates, rapid increase in distinct IPs, and sudden growth in returned data volume are key signals.

  2. 2. BOLA/IDOR'ı nasıl otomatik tararım?

    Fuzzing tools, parameter tampering scripts ve DAST araçları ile enum ve tamper testleri uygulayın; ayrıca owner‑based unit tests ekleyin.

  3. 3. Rate limiting'i nasıl belirlemeliyim?

    Per‑endpoint kullanım profiline göre burst ve sustained limitler belirleyin; business critical endpoint'ler için daha esnek, public endpoints için daha sıkı limitler tanımlayın.

  4. 4. Webhooks nasıl güvenle yönetilir?

    Signed payloads (HMAC), replay prevention (nonce/timestamp), mutual TLS ve per‑tenant secret kullanın; ayrıca webhook URLs'lerini whitelisting ile yönetin.

  5. 5. API keys ve secrets nasıl saklanmalı?

    Secrets manager veya vault kullanılmalı; secrets as code yapılmamalı ve rotate politikaları uygulanmalıdır. Client tarafına minimal, kısa ömürlü kimlikler verin.

  6. 6. Exposed data'ı azaltmak için en etkili adım nedir?

    Response shaping ile sadece gerekli alanları döndürmek. Field‑level filtering ve data minimization politikaları uygulayın.

  7. 7. API güvenliği için manuel pentest yeterli mi?

    Hayır. Otomasyon (DAST/SAST/fuzzing), observability ve manuel pentest kombinasyonu en iyi sonuç verir. Sürekli test ve regresyon sağlanmalıdır.

  8. 8. Small teams için öncelik ne olmalı?

    Inventory (OpenAPI), rate limiting, short‑lived tokens ve monitoring ile başlayın; ardından automated scanning ve policy as code adımlarına geçin.

Anahtar Kavramlar

  • BOLA / IDOR: Object level authorization hataları.
  • Excessive Data Exposure: Gerekenden fazla veri döndürme durumu.
  • Rate limiting: İstek hızını sınırlama mekanizması.
  • Token rotation: Token'ların yenilenmesi ve eski token'ların iptal edilmesi.
  • API Posture Management: API yüzeyinin ve konfigürasyonlarının sürekli değerlendirilmesi.

Öğrenme Yol Haritası

  1. 0–1 ay: REST/HTTP temel kavramları, OpenAPI ile küçük API'ler oluşturma, TLS ve basic auth anlayışı.
  2. 1–3 ay: OAuth2/OIDC, JWT, token lifecycle, short‑lived token ve refresh patterns üzerinde pratik yapın.
  3. 3–6 ay: API security tooling (SAST/DAST, fuzzing), rate limiting stratejileri, webhook security ve signed payload uygulamaları yapın.
  4. 6–12 ay: Service mesh, policy as code (OPA/Rego), AI destekli abuse detection ve API posture management çözümleri ile ileri seviye çalışmalar yapın.