AI Tarafından Üretilen Kodda Güvenlik Kontrolü Nasıl Yapılır?

AI tarafından üretilen kodun çalışması güvenli olduğunu kanıtlamaz. Bu rehber kendi projenizde SQL, çıktı kaçışı, secret ve yetkilendirme kontrolleri yapmanız için başlangıçtır; tarama sonucu temiz çıkınca bütün açıkların kapandığını söylemez.

1. Riskli noktaları satır içeriğini ifşa etmeden bulun

Ripgrep kurulu geliştirme ortamında proje kökünde:

rg -l --glob '!vendor/**' --glob '!node_modules/**' 'eval\(|shell_exec|unserialize\(|move_uploaded_file' .
rg -l --hidden --glob '!.git/**' --glob '!vendor/**' --glob '!node_modules/**' 'BEGIN .*PRIVATE KEY|api[_-]?key|secret' .

-l yalnız dosya adlarını listeler; şüpheli secret değerlerini terminal çıktısına dökmez. Eşleşme açık bulunduğu anlamına gelmez; dosyayı yetkili ortamda inceleyin. Gerçek anahtar depoya girmişse dosyadan silmenin yanında iptal/yenileme yapın; Git geçmişi de değerlendirilmelidir.

2. SQL ve HTML bağlamını ayırın

Aşağıdaki parça mevcut PDO bağlantısıyla herkese açık ürün aramasını örnekler:

$term = $_GET['q'] ?? '';
if (!is_string($term) || strlen($term) > 200) {
    http_response_code(400); exit;
}
$stmt = $pdo->prepare('SELECT id, name FROM products WHERE name LIKE :term LIMIT 20');
$stmt->execute(['term' => '%' . $term . '%']);
foreach ($stmt->fetchAll(PDO::FETCH_ASSOC) as $product) {
    echo '<p>' . htmlspecialchars($product['name'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') . '</p>';
}

Prepared statement SQL verisini ayırır; htmlspecialchars HTML metin bağlamını korur. Bu örnekte % ve _ arama jokeri olarak kalır; literal arama gerekiyorsa ayrıca LIKE kaçışı gerekir. URL, JavaScript ve HTML attribute bağlamlarının kuralları aynı değildir.

3. Yetki testini iki hesapla yapın

Test ortamında iki normal hesap oluşturun. A hesabının sipariş isteğindeki id'yi B hesabının kaydıyla değiştirin; sunucu reddetmeli. Butonu gizlemek veya tahmin edilmesi zor id kullanmak sahiplik kontrolünün yerine geçmez. Admin endpoint'leri her istekte rol denetimi yapmalı.

4. Form ve upload kontrolleri

Durum değiştiren formlarda CSRF token eksik/yanlış olduğunda işlem yapılmamalı. Dosya yüklemede boyut, gerçek MIME ve uzantı kontrolü; sunucunun ürettiği dosya adı ve web kökü dışında saklama değerlendirilir. Kullanıcının filename/path değerini dosya sistemine doğrudan birleştirmeyin. Parolaları password_hash/password_verify ile yönetin; düz metin saklamayın.

5. Bağımlılık ve düzeltme testi

composer audit
npm audit --omit=dev

Yalnız kullandığınız paket yöneticisinin komutunu çalıştırın. Otomatik major sürüm yükseltmesini doğrulamadan canlıya taşımayın. Her düzeltmede önce başarısız olması gereken isteği, sonra normal kullanıcı akışını sınayın; açık kapatılırken sipariş/form işlevi bozulmamalı.

İlgili UST Bilişim kaynakları

Bilgi Merkezi içindeki diğer teknik rehberleri ve web tasarım hizmetimizi inceleyebilirsiniz.