API güvenlik taraması: CORS, JWT, GraphQL ve yanıt sızıntıları

Rehber · API güvenliği

Modern web uygulamalarının büyük bölümü API’ler üzerinden çalışıyor. Kullanıcı girişi, profil bilgileri, ödeme işlemleri, siparişler ve uygulamanın iş mantığının önemli bir kısmı API katmanından geçiyor.

Bu da API’leri saldırganlar için önemli bir hedef haline getiriyor. OWASP’ın API Security Top 10 listesinde de kimlik doğrulama ve yetkilendirme problemlerinin yanı sıra veri sızıntıları, güvenlik yapılandırmaları, kaynak tüketimi ve SSRF gibi API’ye özgü riskler öne çıkıyor.

Peki bir API’nin gerçekten güvenli olup olmadığını nasıl anlayabiliriz?

Guardbee, API güvenlik taramasında yalnızca endpoint’lerin erişilebilir olup olmadığına bakmaz. API’nin nasıl davrandığını, hangi bilgileri açığa çıkardığını ve farklı istek senaryolarında ne kadar erişim sağladığını analiz eder.

Bu yazıda özellikle dört önemli alanı inceleyeceğiz:

• CORS
• JWT ve authentication
• GraphQL
• API response / data leakage

API güvenliği neden farklıdır?

Bir web sitesini ziyaret ettiğinizde gördüğünüz arayüz, uygulamanın yalnızca görünen kısmıdır.

Basitleştirilmiş bir mimari:

Browser
   │
   ▼
Frontend
   │
   ▼
API
   │
   ├── Authentication
   ├── Authorization
   ├── Business Logic
   └── Data
        │
        ▼
    Database

Frontend’de bir butonun görünmemesi, API’nin o işlemi engellediği anlamına gelmez.

Örneğin frontend şu isteği gönderiyor olabilir:

GET /api/users/123

Saldırgan ise request’i değiştirerek şunu gönderebilir:

GET /api/users/124

Sunucu 124 numaralı kullanıcının bilgilerini de döndürüyorsa problem frontend’de değil, API’nin authorization katmanındadır.

Bu nedenle API security testlerinde yalnızca “endpoint çalışıyor mu?” sorusu yeterli değildir.

1. CORS güvenlik kontrolü

CORS, browser’ın farklı origin’ler arasında API isteği yapmasına hangi koşullarda izin verileceğini belirler.

Örneğin:

https://app.example.com
          │
          ▼
https://api.example.com

API şu header’ı döndürebilir:

Access-Control-Allow-Origin: https://app.example.com

Bu durumda API belirli bir origin’e izin vermektedir. Ancak şu gibi geniş bir politika da kullanılabilir:

Access-Control-Allow-Origin: *

Burada önemli nokta şudur: wildcard CORS tek başına her zaman güvenlik açığı değildir.

Public olarak tüketilmesi gereken bir API için bu yapılandırma bilinçli olabilir. Risk, CORS politikasının authentication ve hassas verilerle nasıl birleştiğine bağlıdır.

OWASP da CORS politikasının API’nin kullanım amacına uygun ve spesifik şekilde yapılandırılmasını öneriyor. CORS hatalı yapılandırıldığında API güvenlik yapılandırması problemi haline gelebilir.

Guardbee nasıl analiz eder?

Guardbee API response’larını inceleyerek örneğin şu header’ları analiz eder:

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

Ardından farklı Origin değerleriyle kontrollü istekler göndererek sunucunun davranışını karşılaştırabilir. Örneğin:

Origin: https://example.com

Origin: https://attacker.example

Sonuçlar farklı mı? Sunucu saldırgan tarafından gönderilen Origin’i kabul ediyor mu? Credential kullanımına izin veriliyor mu?

Guardbee bu bilgileri birlikte değerlendirerek salt header kontrolünden daha anlamlı bir risk analizi oluşturabilir.

2. JWT güvenliği

JWT, API’lerde kullanıcı kimliğinin taşınması için yaygın olarak kullanılan bir token formatıdır. Örneğin:

Authorization: Bearer <JWT>

JWT genel olarak üç bölümden oluşur: Header.Payload.Signature.

Payload içerisinde şu gibi bilgiler bulunabilir:

{
  "sub": "123",
  "role": "user",
  "exp": 1780000000
}

Ancak JWT kullanmak otomatik olarak güvenli authentication anlamına gelmez. API’nin token’ı doğru şekilde doğrulaması gerekir.

Token expiration

Token’ın exp değeri geçmiş olmasına rağmen API token’ı kabul ediyorsa authentication mekanizmasında problem olabilir. Guardbee expired token ile kontrollü bir request göndererek sunucunun davranışını analiz edebilir.

Algorithm validation

JWT header’ında kullanılan algoritmanın sunucu tarafından güvenli şekilde doğrulanması gerekir. Örneğin:

{
  "alg": "RS256"
}

gibi bir token oluşturulmuşsa backend’in yalnızca beklediği algoritmaları kabul etmesi önemlidir. Guardbee burada JWT’nin yalnızca decode edilmesine değil, server-side validation davranışına odaklanır.

Claim validation

JWT içerisindeki iss, aud, exp, nbf, sub gibi claim’ler uygulamanın authentication modeline göre önem taşıyabilir. Örneğin sunucu belirli bir audience bekliyorsa farklı audience içeren token’ın kabul edilmesi kontrol edilmelidir.

JWT içerisinde hassas veri

JWT payload’ı çoğu durumda istemci tarafından okunabilir. Bu nedenle şu gibi hassas bilgilerin token içine konulması risk oluşturabilir:

{
  "userId": 123,
  "email": "user@example.com",
  "role": "admin",
  "apiKey": "..."
}

Guardbee response ve token analizlerinde secret, API key, token ve benzeri hassas alanları tespit ederek bunları ayrı bir güvenlik bulgusu olarak değerlendirebilir.

3. GraphQL güvenliği

GraphQL, REST’ten farklı bir API yaklaşımıdır. REST’te farklı endpoint’ler bulunabilir:

GET /users
GET /users/123
GET /orders
GET /products

GraphQL’de ise çoğu zaman merkezi bir endpoint bulunur:

POST /graphql

İstemci hangi alanlara ihtiyacı olduğunu sorgu içerisinde belirtir:

query {
  user {
    id
    name
    email
  }
}

Bu esneklik geliştiriciler için güçlüdür ancak API güvenliği açısından ayrıca değerlendirilmesi gereken riskler oluşturur.

GraphQL introspection

GraphQL’in introspection özelliği API’nin schema yapısı hakkında bilgi sağlayabilir. Örneğin:

{
  __schema {
    types {
      name
    }
  }
}

ile schema hakkında bilgi alınabilir. Bu bilgiler query’ler, mutation’lar, type’lar, field’lar ve argument’lar hakkında saldırgana yol gösterebilir.

OWASP, özellikle production veya public erişime açık GraphQL API’lerinde introspection ve GraphiQL erişiminin ihtiyaç doğrultusunda sınırlandırılmasını öneriyor.

Guardbee nasıl kontrol eder?

Guardbee GraphQL endpoint’ini tespit ettiğinde introspection sorgularının erişilebilir olup olmadığını test eder:

/graphql
     │
     ▼
Introspection Request
     │
     ├── Allowed
     └── Blocked

Sonuç, API’nin public/internal kullanım durumuyla birlikte değerlendirilerek raporlanabilir. Çünkü introspection’ın açık olması tek başına kritik bir vulnerability değildir. Public API’nin bilinçli olarak schema discovery sunması ile internal API’nin tüm schema’sını anonim kullanıcılara açması aynı risk seviyesinde değildir.

4. GraphQL query depth ve resource abuse

GraphQL’in önemli özelliklerinden biri nested query’lerdir. Örneğin:

query {
  user {
    posts {
      author {
        posts {
          author {
            posts {
              title
            }
          }
        }
      }
    }
  }
}

Çok derin veya maliyetli sorgular kontrol edilmezse backend üzerinde gereksiz CPU, memory ve database yükü oluşturabilir.

OWASP GraphQL rehberi bu nedenle query depth, amount, complexity, timeout ve rate limiting gibi kontroller öneriyor.

Guardbee GraphQL endpoint’inde query depth, response size, nested object davranışı, batch request davranışı, error response ve rate/resource abuse sinyalleri gibi göstergeleri analiz ederek API’nin kötüye kullanıma ne kadar açık olduğunu değerlendirebilir.

5. API response data leakage

API güvenliğinde en sık gözden kaçan problemlerden biri de gereğinden fazla veri döndürülmesidir.

Örneğin frontend yalnızca şunu kullanıyor olabilir:

{
  "name": "Ahmet",
  "email": "ahmet@example.com"
}

Fakat API şu yanıtı döndürüyor olabilir:

{
  "id": 123,
  "name": "Ahmet",
  "email": "ahmet@example.com",
  "passwordHash": "...",
  "internalUserId": 84721,
  "resetToken": "...",
  "role": "admin",
  "internalNotes": "..."
}

Frontend bu alanları göstermese bile veri artık browser’a ulaşmıştır. Bu nedenle “kullanıcı arayüzünde görünmüyor” güvenli olduğu anlamına gelmez.

OWASP API Security Top 10 2023, bu problemi object property level authorization kapsamında ele alıyor.

Guardbee response analysis nasıl çalışır?

Guardbee API response’larını yalnızca HTTP status code açısından değerlendirmez. Response içerisindeki alanları analiz eder. Örneğin:

{
  "user": {
    "id": 123,
    "email": "user@example.com",
    "passwordHash": "...",
    "apiKey": "...",
    "internalRole": "admin"
  }
}

Guardbee alanları farklı risk kategorilerine ayırabilir:

• id → Identifier
• email → Personal Data
• passwordHash → Sensitive Credential
• apiKey → Secret
• internalRole → Internal Information

Böylece yalnızca “response büyük” demek yerine “API response içerisinde authentication veya secret niteliğinde hassas alan tespit edildi” gibi geliştiricinin doğrudan aksiyon alabileceği bir bulgu oluşturulur.

6. Error response security

API’nin hata mesajları da saldırgana bilgi sağlayabilir.

Güvenli bir production response şöyle olabilir:

{
  "error": "Internal server error"
}

Riskli bir response ise internal bilgileri açığa çıkarabilir:

{
  "error": "SqlException",
  "database": "production_db",
  "server": "db-prod-01",
  "stack": "at Microsoft.Data.SqlClient..."
}

Bu tür bilgiler kullanılan database, backend teknolojisi, server isimleri, filesystem path’leri, stack trace ve internal service bilgileri hakkında ipuçları verebilir.

OWASP API Security rehberi de stack trace ve hassas hata bilgilerinin response içerisinde döndürülmemesini özellikle öneriyor. Guardbee hata senaryolarını da analiz ederek bu tip bilgi sızıntılarını tespit edebilir.

Guardbee API security scan akışı

Guardbee’nin API güvenlik yaklaşımını basitleştirirsek süreç şu şekilde düşünülebilir:

                 Target
                   │
                   ▼
            API Discovery
                   │
          ┌────────┴────────┐
          │                 │
         REST            GraphQL
          │                 │
          └────────┬────────┘
                   ▼
          Authentication
                   │
                   ▼
           Security Tests
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
     CORS         JWT       GraphQL
       │           │           │
       └───────────┼───────────┘
                   ▼
          Response Analysis
                   │
                   ▼
         Authorization Tests
                   │
                   ▼
             Risk Engine
                   │
                   ▼
          Guardbee Security
               Report

Buradaki önemli nokta, Guardbee’nin kontrolleri birbirinden bağımsız değerlendirmek yerine birlikte analiz edebilmesidir.

Örneğin CORS misconfiguration + authenticated endpoint + sensitive response, tek başına üç farklı düşük riskli bulgu olmaktan çıkıp daha önemli bir saldırı senaryosuna dönüşebilir.

Neden sadece otomatik header kontrolü yetmez?

API güvenliğinde statik kontroller faydalıdır ancak yeterli değildir.

Örneğin Access-Control-Allow-Origin: * bulmak kolaydır. Fakat bunun gerçek riskini anlamak için API’nin public olup olmadığı, authentication gerekip gerekmediği, cookie kullanılıp kullanılmadığı, sensitive data dönüp dönmediği ve credentials kabul edilip edilmediği gibi soruların cevaplanması gerekir.

Aynı şekilde GraphQL introspection enabled bulmak kolaydır. Ancak bunun riskini anlamak için API’nin public olup olmadığı, anonymous access, sensitive mutation’lar ve admin field’ların expose edilip edilmediği gibi context bilgileri gerekir.

Guardbee’nin amacı tam olarak bu noktada statik taramadan davranışsal güvenlik analizine geçmektir.

API security ve OWASP

Guardbee’nin API güvenlik kontrolleri OWASP API Security yaklaşımıyla ilişkilendirilebilir. Özellikle:

• JWT / Authentication → API2 – Broken Authentication
• BOLA / IDOR → API1 – Broken Object Level Authorization
• Response Data Leakage → API3 – Broken Object Property Level Authorization
• Query / Resource Abuse → API4 – Unrestricted Resource Consumption
• Admin endpoint erişimi → API5 – Broken Function Level Authorization
• CORS / Debug / Configuration → API8 – Security Misconfiguration
• API Discovery → API9 – Improper Inventory Management
• Third-party API davranışı → API10 – Unsafe Consumption

OWASP’ın 2023 API Security Top 10 listesi bu riskleri API’lere özgü saldırı yüzeyleri üzerinden sınıflandırıyor.

Sonuç

API güvenliği yalnızca authentication mekanizmasının çalışıp çalışmadığını kontrol etmek değildir. Gerçek bir API güvenlik değerlendirmesi şu soruların tamamına bakmalıdır:

• Kim erişebiliyor?
• Neye erişebiliyor?
• Hangi işlemleri gerçekleştirebiliyor?
• API gereğinden fazla veri döndürüyor mu?
• Authentication token’ları doğru doğrulanıyor mu?
• GraphQL sorguları kötüye kullanılabilir mi?
• CORS politikası güvenli mi?
• Hata mesajları sistem hakkında bilgi sızdırıyor mu?

Guardbee, API güvenlik taramasında bu kontrolleri bir araya getirerek yalnızca teknik bir açık listesi oluşturmak yerine, API’nin gerçek saldırı yüzeyini ve tespit edilen risklerin nasıl giderileceğini görünür hale getirmeyi amaçlar.

API güvenliğinde amaç daha fazla alarm üretmek değil, gerçekten düzeltilmesi gereken riskleri doğru bağlamda ortaya çıkarmaktır.

Sık sorulan sorular

Guardbee API taramasında kimlik bilgisi ister mi?

Authenticated Crawl için markada tanımlı giriş bilgisi gerekir. CORS, JWT, GraphQL introspection ve response analysis kontrolleri genel olarak kimliksiz veya keşfedilen trafik üzerinden çalışabilir.

Wildcard CORS her zaman güvenlik açığı mıdır?

Hayır. Public API’lerde bilinçli olabilir. Risk, CORS politikasının authentication, credentials ve hassas veriyle nasıl birleştiğine bağlıdır.

GraphQL introspection açık olması kritik midir?

Tek başına her zaman kritik değildir. Public API’de bilinçli schema discovery ile internal API’nin tüm schema’sını anonim kullanıcılara açmak farklı risk seviyelerindedir.

JWT kullanmak API’yi güvenli yapar mı?

Hayır. Token’ın sunucu tarafında doğru doğrulanması, expiration, algorithm ve claim kontrolleri ile hassas verinin payload’a konmaması gerekir.

Frontend’de görünmeyen alanlar güvenli midir?

Hayır. API response browser’a ulaştıysa veri sızmış sayılır. Object property level authorization bu yüzden kritiktir.

Guardbee yıkıcı (destructive) API testi yapar mı?

Hayır. Kontrollü ve sınırlı probe’lardır; amacı davranışı gözlemlemek ve riski bağlamlandırmaktır.