SQL Enjeksiyon Saldırılarına Karşı PHP'de Alınacak Önlemler
22
meliharslanoglu4535 Efsane
208 görüntülenme · 22 yorum

SQL Enjeksiyon Saldırılarına Karşı PHP'de Alınacak Önlemler

(21 oy, 3.9/5)

SQL Enjeksiyon Nedir?

SQL enjeksiyon, saldırganların uygulamanızdaki veritabanı sorgularına müdahale etmesine olanak tanıyan bir güvenlik açığıdır. PHP'de bu saldırılara karşı alınması gereken önlemleri detaylı olarak inceleyelim.

1. Prepared Statements Kullanın (En Önemlisi)

Kesinlikle kaçınılması gereken:

$db->query("SELECT * FROM users WHERE id = ". $_GET['id']); 

Doğru kullanım:

$stmt = $db->prepare("SELECT * FROM users WHERE id =? ");
$stmt->execute([(int)$_GET['id']]); 

2. Girdi Doğrulama

$email = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL);
$yas = filter_input(INPUT_POST, 'yas', FILTER_VALIDATE_INT, ['options' => ['min_range' => 0]]); 

3. Dinamik Tablo İsimleri

Dinamik tablo veya sütun isimleri kullanmanız gerekiyorsa, bir beyaz liste (whitelist) kullanın:

$izinliSutunlar = ['isim', 'email', 'tarih'];
$sutun = $_GET['sirala']? ? 'tarih';
if (! in_array($sutun, $izinliSutunlar, true)) {
 $sutun = 'tarih';
}

Güvenlik önlemleri konusunda eksikleriniz varsa bu yöntemleri hemen uygulamaya başlayın. Sorularınız varsa yorum bırakın.

Bu yazıda ne öğreneceksiniz?
  • SQL Enjeksiyon Saldırılarına Karşı PHP' de Alınacak Önlemler konusunun temelleri
  • Pratik ipuçları ve dikkat edilmesi gerekenler
  • 2026 güncel öneriler

Sıkça Sorulan Sorular

Bu yöntem yeni başlayanlar için uygun mu?

Evet, temel adımları takip ederek başlanabilir; ileri seviye detaylar sonraya bırakılabilir.

Ne kadar sürede sonuç alınır?

Doğru kurulumla ilk sonuçlar genellikle birkaç saat içinde görülür.

Mobil cihazlarda da geçerli mi?

Çoğu modern çözüm mobil uyumludur; yine de cihaz bazlı test önerilir.

Kısa notlar tutmak, aynı hatayı tekrar yaşamamanızı sağlar.

Kategori: Tanışma Alanı · Güncelleme: 2026

İlgili Konular

  • 2026 Yılında Tanışma Alanı ve Sosyal Medyada Takipçi Kasma Rehberi: Profesyonel Stratejiler
  • SQL Enjeksiyon Saldırılarına Karşı PHP'de Alınacak Önlemler Hakkında Tartışmalar ve Yorumlar

    En Çok Beğenilen Yorum (2 ❤️)
    mervebaran2096 · 17.07.2026 14:50
    Öncelikle prepared statements konusunu çok güzel açıklamışsınız, ama aklıma takılan bir şey var. `$_GET['id']` değerini `(int)` ile cast etmek prepared statements'in yanında ekstra bir koruma mı sağlıyor yoksa sadece veri tipini mi düzeltiyor? Ayrıca girdi doğrulama kısmını merak ediyorum, orada hangi filtreleme yöntemlerini öneriyorsunuz?
    ardaÖzer4399 1 yorum
    15.07.2026 22:00 (düzenlendi)

    Ben de benzer bir projede bu yöntemi kullanmıştım. Gerçekten işe yarayan bir yaklaşım. Paylaşım için teşekkürler.

    oyaatalay856 1 yorum
    16.07.2026 05:48 (düzenlendi)
    Özellikle prepared statements örneğindeki fark çok net ortaya konmuş. Birinci yöntemde doğrudan $_GET['id'] string birleştirme ile sorguya ekleniyor, bu tam bir felaket davetiyesi. İkinci yöntemdeki prepare ve execute kullanımı ile parametre birbirinden ayrılıyor, yani ne girilirse girilsin sorgunun yapısı değişmiyor. Benzer sorunları bir zamanlar$_POST ile filtreleme yaparak çözmeye çalışıyorduk ama gördük ki input validation tek başına yeterli olmuyor, prepared statements olmadan güvenlik zırhında delik kalıyor.
    16.07.2026 10:39 (düzenlendi)

    İşte bu yüzden bu forumu seviyorum. Her gün yeni bir şey öğreniyorum. Paylaşım kültürü çok değerli bir şey.

    reyhantas9142 1 yorum
    16.07.2026 12:42 (düzenlendi)

    Yazıdaki noktaların hepsi çok önemli. Özellikle performans konusuna değinmeniz çok iyi olmuş. Hız her şeydir.

    utkusari2798 1 yorum
    16.07.2026 13:26 (düzenlendi)
    Ben de uzun süre `$db->query()` ile doğrudan kullanıcı girdisini sorguya ekleyerek yazdım, ta ki bir projemde birisi `? id=1 OR 1=1` diyerek tüm tabloyu çekene kadar. O günden beri `prepare()` ve `? ` placeholder'ı vazgeçilmezim oldu. Özellikle `(int)` ile type casting yapmak çok doğru bir adım, $_GET'ten gelen her şeyi string olarak alıp direkt sorguya atmak büyük risk gerçekten.
    İlkerkilic1289 1 yorum
    16.07.2026 17:15 (düzenlendi)
    Özellikle Prepared Statements örneğindeki fark çok net özetlenmiş, $_GET['id'] doğrudan sorguya concatenated_mi yerine? işaretiyle parametreli sorgu kullanmak gerçekten temel adım. Benzer bir hatayı geçmişte live site'da görmüştüm, $_GET['kullanici'] direkt sorguya atılınca veritabanından tüm kullanıcı bilgileri sızdı. Keşke girdi doğrulama kısmı da aynı örneklerle desteklenseymiş, Prepared Statements kadar kritik olan o katman da en azından parseInt veya filter_var gibi somut karşılıklarla anlatılsa daha tam olurdu.
    minebas6066 1 yorum
    17.07.2026 03:04 (düzenlendi)

    Harika olmuş, teşekkürler. Özellikle güvenlik konusundaki uyarılar çok yerinde. Her geliştiricinin okuması gereken bir yazı.

    17.07.2026 06:22 (düzenlendi)
    Prepared statements kullanıyorsan zaten `(int)$_GET['id']` şeklinde execute içinde tip dönüşümü yapmana gerek yok, çünkü prepared statement'ın kendisi zaten veritabanına güvenli şekilde parametre bağlıyor – bu biraz gereksiz çift koruma oluyor. Ayrıca makale "Girdi Doğrulama" kısmında kesilmiş, yani input validation, escape fonksiyonları, least privilege principle gibi prepared statements dışında kalan diğer kritik önlemleri hiç ele almamış. Sadece prepared statements'e yüklenip "en önem
    aslikeskin5986 1 yorum
    17.07.2026 06:59 (düzenlendi)
    Gerçekten Prepared Statements konusunu çok doğru vurgulamışsınız, ben eski bir projemde tam o "$_GET['id']" direkt sorguya eklenen kullanım yüzünden ciddi sıkıntı yaşamıştım. Kullanıcı adı yerine `1 OR 1=1` gibi bir şey girince tüm user tablosu dökülmüştü, o gün Prepared Statements'ı hayatıma soktum. Girdi doğrulama kısmını da merak ediyorum, devamını bekliyoruz.
    tanerÇetin2695 1 yorum
    17.07.2026 07:22 (düzenlendi)
    Hazırlıklı ifadelerin (prepared statements) ne kadar kritik olduğunu vurgulaman çok yerinde, özellikle `$_GET['id']` gibi kullanıcı girişlerinin doğrudan sorguya gömülmesi en temel açık zaten. Bir ekleme olarak, Prepared Statements kullanırken veri tipini `(int)` ile baskılamak güzel bir adım ama aynı şekilde String değişkenler için de `$stmt->execute([$değişken])` inde parametrik bağlama yapmak, tek satırda bir`' OR 1=1 --` gibi klasik enjeksiyon denemelerini tamamen etkisiz kılıyor. Benim önerim, projede mutlaka bir `PDO` tabanlı veri erişim sınıfı yazıp tüm sorguları tek bir merkezden yönetmen, böylece bir ekip arkadaşı bile Prepared Statements'e geçmeyi unutsa bile güvenlik katmanını korumuş olursun
    17.07.2026 07:46 (düzenlendi)
    Hazırlanmış sorgular (prepared statements) kısmında `prepare` ve `execute` örneği vermişsin ama `$db` nesnesinin PDO mu mysqli mi olduğu belli değil, bu büyük bir eksiklik çünkü ikisinin kullanım mantığı farklı. Ayrıca `execute` içinde `(int)` ile tip dönüştürmesi yapmışsın ama prepared statement'ın zaten bağlayıcı parametrelerle SQL enjeksiyonu engellediği düşünülürse bu aslında gereksiz bir katman — prepared statement'ın kendisi yeterli, fazladan `int` cast ile "güvenlik katmanı" gibi göstermek kafa karıştırıcı. Girdi doğrulama (input validation) kısmı da yarım kalmış, orada whitelist ve regex
    melihkoc1444 1 yorum
    17.07.2026 07:59 (düzenlendi)
    Harika bir yazı olmuş, özellikle Prepared Statements konusundaki kod örnekleri çok netleştirici. O kaçınılması gereken `$db->query("SELECT * FROM users WHERE id = ". $_GET['id']); ` satırı ile doğru kullanımı yan yana koymanız, aradaki farkı hemen kavramamı sağladı. Bir de Girdi Doğrulama kısmının devamını da eklerseniz tam olur, orada kesmişsiniz gibi duruyor. Teşekkürler, PHP güvenlik konusunda işine yarayacak güzel bir kaynak oldu bu.
    17.07.2026 08:58 (düzenlendi)
    Harika bir yazı olmuş, özellikle Prepared Statements bölümündeki `$db->query("SELECT * FROM users WHERE id = ". $_GET['id']); ` gibi kötü kullanım ile doğru arasındaki karşılaştırma çok net açıklamış. Bir de girdi doğrulama kısmının devamını merakla bekliyorum, orası kesilmiş gibi görünüyor. Bu tarz güvenlik konularında somut kod örnekleri vermek gerçekten çok faydalı oluyor, emeğine sağlık!
    +1 puan
    bernayaman8730 1 yorum
    17.07.2026 10:28 (düzenlendi)
    Prepared Statements konusu gerçekten çok önemli, özellikle `$db->prepare("SELECT * FROM users WHERE id =? ")` kullanımını gösterdiğin kısım çok netleştirici. BirçokPHPdeveloper'ın hâlâ `$_GET['id']` doğrudan query içine attığını düşününce, bu tür örneklerin paylaşılması gerçekten değerli. Girdi doğrulama kısmının devamını da merakla bekliyorum, konu tam olarak anlaşılınca pek çok uygulama çok daha güvenli hale gelecek.
    tamerdemir4607 2 yorum
    17.07.2026 10:45 (düzenlendi)
    Prepared statements konusuna bayıldım, özellikle $_GET['id'] parametresinin (int) ile cast edilmesi çok doğru bir yaklaşım. Bir de şunu eklemek isterim: prepared statements kullanırken sadece `? ` yer tutucusu değil, named parameters (`: id` şeklinde) de kullanılabilir, bu uzun sorgularda kodun okunabilirliğini ciddi artırıyor. Ayrıca veritabanı bağlantı katmanında `$db->setAttribute(PDO: :ATTR_EMULATE_PREPARES, false)` ayarını mutlaka yapmak lazım, aksi halde PDO bazı senaryolarda prepared statement'ları gerçekten prepared olarak çalıştırıp safety sağlamayabiliyor.
    17.07.2026 14:57 (düzenlendi)

    Güzel bir rehber olmuş. Özellikle adım adım anlatım şekli çok başarılı. Yeni başlayanlar mutlaka okumalı.

    +1 puan
    niluferakar9447 1 yorum
    17.07.2026 11:21 (düzenlendi)
    Hazırlıklı ifadeler konusuna kesinlikle katılıyorum, ben de bir dönem $_GET ile direkt sorguya değer basıyordum ve tam da makalede bahsedilen türden bir açık nedeniyle test ortamında veritabanımın tüm tabloları dökülmüştü. $db->prepare ve execute kullanımı gerçekten hayat kurtarıyor, hele ki (int) ile tip dönüşümü yapmak ekstra bir katman sağlıyor. Ben ayrıca girdi doğrulama kısmını da ihmal etmemeye çalışıyorum çünkü prepared statements tek başına yeterli olmayabiliyor, bazen LIKE sorgularında bile wildcard karakterleri sorun çıkarabiliyor.
    sevgigul8462 1 yorum
    17.07.2026 12:06 (düzenlendi)
    Hazırlıklı sorgular (prepared statements) konusuna hassasım, çünkü$_GET['id'] direkt olarak sorguya gömüldüğünde facia yaşanıyor zaten. Parantez içindeki (int) dönüşümü ile birlikte prepare/execute akışının gösterilmesi çok yerinde olmuş, tam da yeni başlayanların ihtiyacı olan somut örnek. Girdi doğrulama kısmının devamını da merakla bekliyorum, çünkü prepared statements tek başına yeterli değil maalesef.
    okanÖzkan2357 1 yorum
    17.07.2026 13:30 (düzenlendi)
    Uzun süre $_GET ve $_POST değerlerini doğrudan sorguya monte ederek kullandım, ta ki bir projede login formundan saldırganlar veritabanına erişene kadar. O günden sonra prepared statements'e tamamen geçtim, özellikle $db->prepare() ile parametre bindirme işini asla atlamıyorum. Girdi doğrulama kısmını da ekleyince, Integer casting (int) $_GET['id'] gibi basit bir önlem bile ne kadar büyük fark yaratıyor, insan inanamıyor.
    +1 puan
    mervebaran2096 1 yorum
    17.07.2026 14:50 (düzenlendi)
    Öncelikle prepared statements konusunu çok güzel açıklamışsınız, ama aklıma takılan bir şey var. `$_GET['id']` değerini `(int)` ile cast etmek prepared statements'in yanında ekstra bir koruma mı sağlıyor yoksa sadece veri tipini mi düzeltiyor? Ayrıca girdi doğrulama kısmını merak ediyorum, orada hangi filtreleme yöntemlerini öneriyorsunuz?
    +2 puan
    1 2

    İlgili Konular