Web Sitelerinde API Güvenliği: REST API Geliştirirken Yapılan 7 Kritik Hata

Yesterday at 08:38 OP

Thread Starter #1

Günümüzde web siteleri, mobil uygulamalar ve üçüncü taraf servisler arasındaki veri alışverişinin büyük bölümü API'ler üzerinden gerçekleştiriliyor. Özellikle REST API mimarisi, modern web projelerinde oldukça yaygın bir şekilde kullanılıyor.
Ancak API geliştirmek yalnızca verileri JSON formatında sunmaktan ibaret değildir. Kimlik doğrulama, yetkilendirme, hız sınırlandırması ve veri doğrulama gibi konular göz ardı edildiğinde ciddi güvenlik açıkları ortaya çıkabilir.
Bu yazıda REST API geliştirirken dikkat edilmesi gereken 7 önemli hatayı inceleyelim.

1. Kimlik Doğrulama Olmadan Hassas Verileri Sunmak

Bir API endpoint'inin herkese açık olması, tüm verilerin herkes tarafından görüntülenebilmesi gerektiği anlamına gelmez.
Örneğin aşağıdaki endpoint, kullanıcıların özel bilgilerini koruma olmadan sunuyorsa ciddi bir güvenlik sorunu oluşturabilir:

CODE

1GET /api/users

Hassas verilere erişim gerektiğinde kimlik doğrulama uygulanmalı ve yalnızca gerekli bilgilerin döndürülmesi sağlanmalıdır.
API anahtarları veya erişim token'ları da URL parametrelerinde taşınmak yerine uygun HTTP başlıklarında gönderilmelidir.

2. Kimlik Doğrulama ile Yetkilendirmeyi Karıştırmak

Bir kullanıcının sisteme giriş yapmış olması, tüm kaynaklara erişebileceği anlamına gelmez.
Örneğin kullanıcı

CODE

numaralı siparişini görüntüleyebiliyor diye

CODE

numaralı siparişi de görüntüleyebilmemelidir.
Sunucu, her istekte kullanıcının ilgili kaynağa erişim yetkisini kontrol etmelidir. Bu tür kontrollerin eksikliği, nesne düzeyinde yetkilendirme açıklarına (BOLA/IDOR) neden olabilir.

3. Gelen Verileri Doğrulamamak

İstemciden gelen hiçbir veriye otomatik olarak güvenilmemelidir.
Örneğin bir kullanıcı kayıt endpoint'inde e-posta adresi, kullanıcı adı ve parola gibi alanlar kontrol edilmelidir.
PHP tarafında temel bir kontrol şu şekilde yapılabilir:

CODE

12345678910111213<?php

$email = $_POST['email'] ?? '';

if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    http_response_code(400);

    echo json_encode([
        'error' => 'Geçersiz e-posta adresi.'
    ]);

    exit;
}

Bu örnek yalnızca e-posta biçimini kontrol eder. Gerçek bir API'de JSON gövdesinin doğrulanması, zorunlu alanlar, veri uzunlukları ve iş kuralları da ayrıca ele alınmalıdır.

4. SQL Injection Riskini Göz Ardı Etmek

Kullanıcı girdilerini doğrudan SQL sorgularına eklemek, veritabanı güvenliğini tehlikeye atabilir.
Riskli yaklaşım:

CODE

1$sql = "SELECT * FROM users WHERE email = '$email'";

Bunun yerine PDO ve hazırlanmış ifadeler kullanılabilir:

CODE

123456789$stmt = $pdo->prepare(
    "SELECT id, email FROM users WHERE email = :email"
);

$stmt->execute([
    'email' => $email
]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

Hazırlanmış ifadeler SQL injection riskini önemli ölçüde azaltır. Bunun yanında veritabanı kullanıcılarına yalnızca ihtiyaç duydukları yetkiler verilmelidir.

5. Rate Limiting Kullanmamak

Bir API'ye kısa sürede çok fazla istek gönderilmesi sunucu kaynaklarını tüketebilir veya parola denemeleri gibi kötüye kullanım senaryolarına yol açabilir.
Rate limiting sayesinde belirli bir zaman aralığında yapılabilecek istek sayısı sınırlandırılabilir.
Örneğin:

Genel API endpoint'leri için makul istek limitleri belirlemek.
Giriş ve parola sıfırlama işlemlerine daha sıkı sınırlar uygulamak.
Limit aşımında
CODE
```
1429 Too Many Requests
```
yanıtı döndürmek.
Proxy arkasında istemci IP adresini güvenli şekilde belirlemek.

Limitler, uygulamanın kullanım şekline göre ayarlanmalıdır. Yalnızca IP adresine dayalı sınırlandırma, bazı senaryolarda yeterli olmayabilir.

6. Hata Mesajlarında İç Sistem Bilgilerini Açığa Çıkarmak

Üretim ortamında SQL hatalarını, dosya yollarını veya ayrıntılı stack trace bilgilerini doğrudan istemciye göndermek doğru değildir.
Bunun yerine istemciye genel ve güvenli bir hata mesajı verilmeli, ayrıntılar erişimi sınırlandırılmış log dosyalarına kaydedilmelidir.
Örneğin:

CODE

1234{
  "error": "Beklenmeyen bir hata oluştu.",
  "request_id": "req_8f31a2"
}

Buradaki

CODE

1request_id

, hata kayıtlarının bulunmasını kolaylaştırmak için kullanılabilir. Gerçek sistemlerde bu kimliğin isteklerle tutarlı biçimde ilişkilendirilmesi gerekir.

7. CORS Ayarlarını Güvenlik Mekanizması Sanmak

CORS, tarayıcıların farklı kaynaklar arasındaki isteklere ilişkin erişim kurallarını belirler. Ancak kimlik doğrulama veya yetkilendirme mekanizmasının yerine geçmez.
Tüm kaynaklara gelişigüzel izin vermek yerine yalnızca ihtiyaç duyulan origin adreslerine izin verilmelidir.
Özellikle kimlik bilgileriyle yapılan tarayıcı isteklerinde CORS yapılandırması dikkatle ele alınmalı; cookie tabanlı oturumlar kullanılıyorsa CSRF koruması da değerlendirilmelidir.

Ekstra: API Güvenliği İçin Kontrol Listesi

Bir API'yi yayına almadan önce şu kontrolleri yapabilirsiniz:

Kimlik doğrulama ve yetkilendirme kontrolleri mevcut mu?
Kullanıcı girdileri doğrulanıyor mu?
SQL sorgularında hazırlanmış ifadeler kullanılıyor mu?
Rate limiting uygulanıyor mu?
Hassas bilgiler yanıtlarda veya loglarda açığa çıkıyor mu?
HTTPS zorunlu tutuluyor mu?
API anahtarları güvenli şekilde saklanıyor mu?
Kullanılmayan endpoint'ler ve gereksiz izinler kaldırılmış mı?

Sonuç

Güvenli bir REST API oluşturmak, yalnızca doğru kod yazmakla değil, erişim kontrollerini ve olası saldırı senaryolarını doğru tasarlamakla mümkündür.
Özellikle kullanıcı verileri, ödeme işlemleri ve yönetim fonksiyonları içeren API'lerde güvenlik kontrolleri geliştirme sürecinin en başından itibaren düşünülmelidir.
Sizin projelerinizde API güvenliği için hangi yöntemleri kullanıyorsunuz?
PHP, Laravel, Node.js veya başka bir teknolojiyle geliştirdiğiniz API'lerde karşılaştığınız güvenlik sorunlarını ve çözüm önerilerinizi yorumlarda paylaşabilirsiniz.

● WEBMASTER ●
Hayatın anlamı bir noktalı virgülde gizlidir.
« every fix is a win »
#DevMood

Leave a rating: Web Sitelerinde API Güvenliği: REST API Geliştirirken Yapılan 7 Kritik Hata

Raters: Web Sitelerinde API Güvenliği: REST API Geliştirirken Yapılan 7 Kritik Hata

1. Kimlik Doğrulama Olmadan Hassas Verileri Sunmak

2. Kimlik Doğrulama ile Yetkilendirmeyi Karıştırmak

3. Gelen Verileri Doğrulamamak

4. SQL Injection Riskini Göz Ardı Etmek

5. Rate Limiting Kullanmamak

6. Hata Mesajlarında İç Sistem Bilgilerini Açığa Çıkarmak

7. CORS Ayarlarını Güvenlik Mekanizması Sanmak

Ekstra: API Güvenliği İçin Kontrol Listesi

Sonuç