Peki, kullanıcı adı alanına normal bir isim yerine SQL komutu yazarsanız ne olur?

Uygulama bu girdiyi doğrudan SQL sorgusuna ekliyorsa veritabanı beklediğinizden farklı bir komut çalıştırabilir. Böylece basit bir metin alanı, veritabanı güvenliğini tehdit eden bir noktaya dönüşür.

Bu güvenlik açığına SQL Injection (SQL enjeksiyonu) adını veriyoruz.

SQL Injection yalnızca eski web uygulamalarının sorunu değil. Modern Java uygulamaları, REST API’ler, mikroservisler ve ORM kullanan sistemler de hatalı sorgu oluşturduklarında aynı riskle karşılaşır.

Bu rehberde SQL Injection’ın nasıl çalıştığını, hangi hataların güvenlik açığı oluşturduğunu ve Java ile güvenli veritabanı sorgularını nasıl geliştirebileceğinizi inceleyeceğiz.

SQL Injection Nedir?

SQL Injection, saldırganın uygulamanın SQL sorgusuna kendi girdisi üzerinden müdahale etmesini sağlayan bir güvenlik açığıdır.

Sorunun temelinde SQL komutları ile kullanıcı verilerinin birbirine karışması yatar.

Bir uygulama kullanıcı girdisini SQL sorgusunun metnine doğrudan eklediğinde, saldırgan sorgunun mantığını değiştirebilir.

Bu durum saldırgana uygulamanın veritabanı izinleri ve sorgunun yapısına bağlı olarak şu fırsatları verebilir:

• Normalde erişemeyeceği verilere ulaşmak
• Kullanıcı hesapları ve müşteri bilgilerini okumak
• Yetkisiz veri değişiklikleri yapmak
• Kayıtları silmek veya bozmak
• Kimlik doğrulama kontrollerini aşmak
• Veritabanı hizmetinin çalışmasını olumsuz etkilemek

Bazı veritabanı özellikleri ve yüksek yetkili hesaplar, saldırının etkisini veritabanının dışına da taşıyabilir.

SQL Injection, OWASP Top 10:2025 listesindeki A05:2025 – Injection kategorisinin kapsamına girer.

Burada önemli nokta şu: SQL dili tek başına güvenlik açığı oluşturmaz. Açığı, uygulamanın güvenilmeyen verileri SQL sözdiziminin parçası hâline getirmesi oluşturur.

SQL Injection Nasıl Çalışır?

Bir e-ticaret uygulamasında kullanıcıların e-posta adresleri üzerinden hesap bilgilerini aradığımızı düşünelim.

Normal koşullarda uygulama şu sorguyu çalıştırır:

SELECT id, email, full_name
FROM customers
WHERE email = 'ali@example.com';

Veritabanı yalnızca ilgili e-posta adresini taşıyan kaydı döndürür.

Şimdi Java tarafında SQL sorgusunu nasıl oluşturduğumuza bakalım.

Güvensiz Java Kod Örneği

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql = "SELECT id, email, full_name " +
                 "FROM customers WHERE email = '" +
                 email + "'";

    try (Statement statement =
             connection.createStatement();
         ResultSet rs = statement.executeQuery(sql)) {

        if (rs.next()) {
            return new Customer(
                rs.getLong("id"),
                rs.getString("email"),
                rs.getString("full_name")
            );
        }

        return null;
    }
}

İlk bakışta kod oldukça basit. Geliştirici e-posta adresini SQL sorgusuna ekliyor ve sorguyu çalıştırıyor.

Ancak şu satır ciddi bir güvenlik problemi yaratıyor:

"FROM customers WHERE email = '" + email + "'"

Uygulama, email değişkeninin içeriğini SQL komutunun bir parçası hâline getiriyor.

Geliştirici burada SQL’in nerede bittiğini ve kullanıcı verisinin nerede başladığını veritabanına güvenilir şekilde anlatmıyor.

Saldırgan Sorguyu Nasıl Değiştirir?

Saldırganın e-posta alanına şu ifadeyi yazdığını düşünelim:

' OR '1'='1'

Uygulama bu ifadeyi sorguya doğrudan eklerse ortaya şu SQL çıkar:

SELECT id, email, full_name
FROM customers
WHERE email = '' OR '1'='1';

Sorgunun mantığı artık değişti.

'1'='1' ifadesi her zaman doğru sonuç verir. Dolayısıyla WHERE koşulu bütün satırlar için doğru olur.

Veritabanı sorgusu tek bir müşteri yerine birden fazla müşteriyi döndürebilir.

Örnekteki Java metodu yalnızca ilk kaydı okuyacak olsa da saldırgan arama sonucunun kapsamını değiştirmiş olur. Uygulamanın geri kalan mantığı bu davranışı hesap erişimi veya yetkilendirme için kullanıyorsa daha ciddi sorunlar ortaya çıkabilir.

Bu örnek, SQL Injection’ın temel mekanizmasını gösterir: Saldırgan veri göndermek yerine sorgunun mantığını değiştirir.

SQL Injection Neden Tehlikelidir?

Saldırının etkisini yalnızca sorgu sonucunda kaç kayıt gördüğümüzle ölçemeyiz.

Veritabanı kullanıcısının yetkileri, uygulamanın işlevleri ve verinin niteliği de sonuçları belirler.

Veri Gizliliğinin Kaybı

Bir uygulama müşteri adreslerini, e-posta bilgilerini veya finansal kayıtları saklıyor olabilir.

SQL Injection açığı, saldırganın bu verilere yetkisiz erişim elde etmesine yol açabilir.

Güvenlik açısından sorun yalnızca verinin dışarı çıkması değildir. Uygulamanın normalde göstermediği bilgilerin başka bir kullanıcıya ulaşması da gizlilik ihlalidir.

Veri Bütünlüğünün Bozulması

Yeterli veritabanı yetkisine sahip bir uygulama üzerinden saldırgan bazı kayıtları değiştirebilir veya silebilir.

Örneğin ürün fiyatları, sipariş durumları ve müşteri hesap bilgileri saldırgan için hedef oluşturabilir.

Bu tür değişiklikler yalnızca teknik hata yaratmaz. İş süreçlerini ve raporların doğruluğunu da etkiler.

Hizmet Kesintileri

Bazı SQL sorguları çok fazla işlemci, bellek veya disk kaynağı tüketebilir.

Saldırganın sorgu davranışını değiştirmesi, veritabanının performansını düşürebilir. Ağır durumlarda uygulama hizmet veremez hâle gelebilir.

Yetkilendirme Sorunları

SQL Injection, kimlik doğrulama ve yetkilendirme mekanizmalarını etkileyebilir.

Ancak her SQL Injection açığı otomatik olarak giriş ekranını aşma imkânı vermez.

Saldırganın hangi işlemleri gerçekleştirebileceğini sorgunun konumu, uygulama mantığı ve veritabanı yetkileri belirler.

SQL Injection Türleri

Güvenlik uzmanları SQL Injection saldırılarını çoğunlukla uygulamanın veritabanından nasıl yanıt aldığına göre sınıflandırır.

1. In-Band SQL Injection

Bu yöntemde saldırgan aynı iletişim kanalı üzerinden hem sorguyu etkiler hem de sonucu görür.

İki yaygın alt türü bulunur.

Error-Based SQL Injection

Saldırgan, veritabanının ürettiği hata mesajlarından teknik bilgi elde etmeye çalışır.

Hata mesajları bazen tablo isimleri, sütunlar veya SQL sözdizimi hakkında ipuçları verebilir.

Union-Based SQL Injection

Saldırgan, uygun koşullarda UNION operatörünü kullanarak farklı sorguların sonuçlarını birleştirmeye çalışır.

Bu yöntem belirli sorgu yapısı ve veri tipi uyumluluğu koşullarını gerektirir.

2. Blind SQL Injection

Bazı uygulamalar sorgu sonucunu veya veritabanı hatalarını doğrudan göstermez.

Bu durum SQL Injection riskini ortadan kaldırmaz.

Saldırgan, uygulamanın davranışındaki küçük farkları gözlemleyerek bilgi elde etmeye çalışabilir.

Boolean-Based Blind SQL Injection

Saldırgan doğru ve yanlış koşullara karşılık uygulamanın farklı tepkiler verip vermediğini inceler.

Time-Based Blind SQL Injection

Saldırgan veritabanının yanıt süresindeki farklılıklardan çıkarım yapmaya çalışır.

Ancak ağ gecikmeleri ve sistem yükü, zaman ölçümlerini yanıltabilir.

3. Out-of-Band SQL Injection

Bazı senaryolarda saldırgan, veritabanının farklı bir iletişim kanalı üzerinden dış sistemlerle etkileşim kurmasını hedefler.

Bu yaklaşım özel veritabanı özellikleri, yapılandırmalar ve ağ erişim koşulları gerektirir.

4. Second-Order SQL Injection

Bu türü özellikle gözden kaçırmak kolaydır.

Uygulama saldırganın girdisini önce veritabanına kaydeder. Daha sonra başka bir işlem bu veriyi okuyup güvensiz biçimde yeni bir SQL sorgusuna ekler.

Dolayısıyla güvenlik açığı ilk veri girişinde değil, verinin sonraki kullanımında ortaya çıkar.

Bu nedenle geliştirici yalnızca HTTP isteklerini değil, veritabanından, dosyalardan ve diğer servislerden gelen verileri de sorgu oluştururken güvenilmeyen girdi olarak ele almalıdır.

SQL Injection Nasıl Önlenir?

SQL Injection’a karşı en güçlü temel savunma, SQL komutlarının yapısını kullanıcı verilerinden ayrı tutmaktır.

OWASP, veri değerleri için parametreli sorguları temel savunma olarak önerir.

1. PreparedStatement ve Parametreli Sorgular Kullanın

Java JDBC API, PreparedStatement sınıfıyla parametreli sorgular oluşturmanıza imkân verir.

Önceki güvensiz örneği yeniden yazalım.

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql = """
        SELECT id, email, full_name
        FROM customers
        WHERE email = ?
        """;

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(1, email);

        try (ResultSet rs =
                 statement.executeQuery()) {

            if (rs.next()) {
                return new Customer(
                    rs.getLong("id"),
                    rs.getString("email"),
                    rs.getString("full_name")
                );
            }

            return null;
        }
    }
}

Burada iki önemli değişiklik yaptık.

İlk olarak kullanıcı girdisini SQL metnine eklemek yerine ? yer tutucusunu kullandık.

İkinci olarak setString() metoduyla parametre değerini sorguya bağladık.

JDBC sürücüsü, parametre bağlama mekanizması üzerinden SQL yapısıyla veri değerini ayrı ele alır.

Artık kullanıcı şu ifadeyi gönderse bile:

' OR '1'='1'

Veritabanı bunu sorgunun mantığını değiştiren bir SQL ifadesi olarak değil, email sütununda aranacak bir değer olarak değerlendirir.

PreparedStatement neden güvenlidir?

Çünkü SQL’in komut yapısı ile dışarıdan gelen veri arasında açık bir sınır kurar.

Tek başına kullanıcı girdisindeki özel karakterleri yasaklamamız gerekmez.

Örneğin O'Connor gibi tek tırnak içeren gerçek isimler de güvenli biçimde işlenebilir.

Ancak geliştirici SQL yapısını kullanıcı girdisiyle birleştirmeye devam ederse yalnızca sorgunun başka bir bölümünde PreparedStatement kullanması yeterli olmaz.

2. Dinamik SQL Yapıları İçin Allowlist Kullanın

Parametreli sorguların önemli bir sınırı bulunur.

? yer tutucusu tablo ismi, sütun ismi veya ASC ve DESC gibi SQL anahtar kelimeleri yerine geçmez.

Bir e-ticaret uygulamasında kullanıcılar ürünleri fiyat veya isim üzerinden sıralamak isteyebilir.

Şu yaklaşım güvenli değildir:

String sql =
    "SELECT id, name, price FROM products ORDER BY "
    + sortBy;

Çünkü uygulama dışarıdan gelen sortBy değerini doğrudan SQL yapısına ekler.

Bunun yerine izin verdiğimiz seçenekleri kodda tanımlayalım.

public String createProductQuery(
        String sortBy,
        String direction
) {
    String column = switch (sortBy) {
        case "price" -> "price";
        case "name"  -> "name";
        default -> throw new
            IllegalArgumentException(
                "Unsupported sort field"
            );
    };

    String order = switch (direction) {
        case "asc"  -> "ASC";
        case "desc" -> "DESC";
        default -> throw new
            IllegalArgumentException(
                "Unsupported direction"
            );
    };

    return """
        SELECT id, name, price
        FROM products
        ORDER BY %s %s
        """.formatted(column, order);
}

Burada kullanıcı yalnızca önceden tanımladığımız seçenekler arasından seçim yapabilir.

Uygulama SQL sorgusuna doğrudan kullanıcı girdisini değil, kendi belirlediği güvenilir SQL ifadelerini ekler.

Dinamik yapıları bu şekilde sınırlandırırken diğer veri değerleri için yine parametreli sorgular kullanmalıyız.

3. Girdi Doğrulama Uygulayın

Bir e-posta alanı e-posta biçimini, bir ürün kimliği ise beklenen veri tipini taşımalıdır.

Girdi doğrulama uygulamanın beklenmedik verilerle karşılaşmasını azaltır.

Ancak doğrulama SQL Injection’a karşı tek başına yeterli değildir.

Örneğin sadece tek tırnak karakterini engellemek güvenilir bir savunma oluşturmaz.

Farklı SQL sözdizimleri, karakter dönüşümleri ve sorgu bağlamları bu tür filtreleri yetersiz bırakabilir.

Doğru yaklaşım şudur:

• Girdi doğrulamayı iş kuralları için kullanın.
• Parametreli sorgularla SQL yapısını koruyun.
• Dinamik SQL parçalarını allowlist ile sınırlandırın.

4. Veritabanında En Az Ayrıcalık İlkesini Uygulayın

Bir uygulamanın yalnızca müşteri listesini okuması gerekiyorsa veritabanı hesabına tüm tabloları değiştirme yetkisi vermemelisiniz.

Örneğin PostgreSQL üzerinde yalnızca ürün okuma görevi olan bir hesap için gerekli erişimi sınırlayabilirsiniz.

REVOKE ALL ON TABLE products
FROM product_reader;

GRANT SELECT ON TABLE products
TO product_reader;

Bu örnek ilgili tablo üzerindeki yetkileri sınırlar. Gerçek sistemde rol üyeliklerini, şema erişimini, varsayılan yetkileri ve diğer tabloları da kontrol etmelisiniz.

En az ayrıcalık ilkesi SQL Injection açığını doğrudan engellemez.

Ancak saldırgan bir açık bulsa bile veritabanı hesabının yapabileceği işlemleri sınırlar.

5. ORM Kullanırken Dinamik Sorgulara Dikkat Edin

Hibernate veya JPA kullanmak SQL Injection riskini otomatik olarak ortadan kaldırmaz.

Örneğin şu JPQL oluşturma biçimi risklidir:

String jpql =
    "SELECT u FROM User u WHERE u.email = '"
    + email + "'";

var query = entityManager.createQuery(
    jpql,
    User.class
);

Güvenli yaklaşımda parametre bağlamalıyız:

var query = entityManager.createQuery(
    """
    SELECT u
    FROM User u
    WHERE u.email = :email
    """,
    User.class
);

query.setParameter("email", email);

List<User> users = query.getResultList();

ORM araçları geliştiricinin işini kolaylaştırır. Ancak sorgu oluşturma kararının güvenliği yine geliştiricinin sorumluluğundadır.

Özellikle native SQL, dinamik JPQL/HQL ve elle oluşturduğunuz sıralama koşullarını dikkatle incelemelisiniz.

6. Stored Procedure Kullanımını da Denetleyin

Stored procedure kullanımı SQL Injection riskini tek başına ortadan kaldırmaz.

Bir procedure içinde kullanıcı verilerini birleştirerek dinamik SQL oluşturursanız aynı güvenlik açığını yeniden yaratabilirsiniz.

Procedure çağrısında parametre bağlamak önemlidir. Ancak procedure içindeki dinamik sorgular için de aynı güvenlik kuralını uygulamalısınız.

Statik SQL tercih edin. Dinamik SQL gerektiğinde veri parametrelerini bağlayın ve SQL yapılarını güvenilir seçeneklerle sınırlandırın.

7. Hata Mesajlarını ve Kayıtları Kontrol Edin

Geliştirme sırasında ayrıntılı SQL hataları sorunları çözmenize yardımcı olur.

Ancak canlı ortamda ham veritabanı hatalarını istemciye göndermek gereksiz bilgi açığa çıkarabilir.

Uygulama, kullanıcıya genel bir hata yanıtı vermeli ve teknik ayrıntıları yetkili ekiplerin erişebileceği güvenli log sisteminde tutmalıdır.

Log kayıtlarına parola, erişim belirteci veya hassas kişisel veri eklemeyin.

Ayrıca veritabanı kullanıcısının izinlerini ve uygulamanın hata yönetimini düzenli olarak inceleyin.

SQL Injection Açıklarını Nasıl Test Edebilirsiniz?

SQL Injection kontrollerini yalnızca sahibi olduğunuz veya açıkça test izni aldığınız sistemlerde gerçekleştirin.

Güvenli bir geliştirme ortamında aşağıdaki yaklaşımı kullanabilirsiniz.

Kod İncelemesi

Öncelikle SQL sorgularını oluşturan kodu inceleyin.

Özellikle şu kalıplara dikkat edin:

• SQL metniyle kullanıcı girdisinin birleştirilmesi
• Statement ile dinamik sorgu çalıştırma
• Native SQL ve dinamik JPQL/HQL oluşturma
• Stored procedure içinde dinamik SQL kullanımı
• ORDER BY ve tablo isimleri gibi yapısal alanlarda kullanıcı girdisi kullanımı

Her Statement kullanımı otomatik olarak açık anlamına gelmez. Asıl risk, güvenilmeyen girdinin SQL komutunun yapısını değiştirebilmesidir.

Otomatik Güvenlik Testleri

Statik uygulama güvenliği testleri (SAST), kaynak kodda şüpheli sorgu oluşturma kalıplarını bulmanıza yardımcı olabilir.

Dinamik uygulama güvenliği testleri (DAST), çalışan uygulamanın girdilere verdiği tepkileri analiz eder.

OWASP ZAP ve uygun yapılandırılmış güvenlik test araçları, yetkili test süreçlerinde yardımcı olabilir.

Bir aracın herhangi bir bulgu üretmemesi uygulamanın kesinlikle güvenli olduğu anlamına gelmez.

Java ile Basit Bir Regresyon Testi

Parametreli sorgunun beklendiği gibi davrandığını birim veya entegrasyon testinde de kontrol edebilirsiniz.

Örneğin aşağıdaki JUnit 5 testi, depo katmanının şüpheli bir girdiyi geçerli müşteri kaydı gibi yorumlamamasını bekler.

@Test
void shouldTreatSqlPayloadAsPlainData()
        throws SQLException {

    String input = "' OR '1'='1";

    Customer result =
        repository.findByEmail(
            connection,
            input
        );

    assertNull(result);
}

Bu testi çalıştırırken izole test veritabanınızda ilgili girdiyi e-posta değeri olarak taşıyan bir kayıt bulunmadığından emin olun.

Testin gerçek değerini artırmak için veritabanını başlangıç verileriyle kurun, bilinen bir müşteri kaydı ekleyin ve sorgunun beklenmedik kayıt döndürmediğini doğrulayın.

Tek bir test bütün SQL Injection türlerini kapsamaz. Ancak daha önce düzelttiğiniz bir açığın tekrar ortaya çıkmasını yakalayabilir.

Bir E-Ticaret Uygulamasında SQL Injection Güvenliği

Bir e-ticaret sisteminin yalnızca giriş ekranını koruduğunu varsayalım.

Bu yeterli değildir.

Ürün arama, fiyat filtreleme, müşteri hesapları, sipariş geçmişi, kampanya sorguları ve yönetim paneli aynı güvenlik prensiplerine ihtiyaç duyar.

Örneğin ürün arama sorgusunu şöyle oluşturabiliriz:

public List<Product> searchProducts(
        Connection connection,
        String keyword,
        BigDecimal maxPrice
) throws SQLException {

    String sql = """
        SELECT id, name, price
        FROM products
        WHERE LOWER(name) LIKE LOWER(?)
          AND price <= ?
        """;

    List<Product> products =
        new ArrayList<>();

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(
            1,
            "%" + keyword + "%"
        );

        statement.setBigDecimal(
            2,
            maxPrice
        );

        try (ResultSet rs =
                 statement.executeQuery()) {

            while (rs.next()) {
                products.add(
                    new Product(
                        rs.getLong("id"),
                        rs.getString("name"),
                        rs.getBigDecimal("price")
                    )
                );
            }
        }
    }

    return products;
}

Bu örnekte iki farklı parametre bağladık.

İlk parametre ürün isminde arama yapıyor. İkinci parametre maksimum fiyatı belirliyor.

keyword değerini Java tarafında % karakterleriyle birleştiriyoruz. Ancak bu birleşim SQL sorgusunun yapısını değil, parametre değerini değiştiriyor.

Bu nedenle sorgu SQL Injection’a karşı güvenli bir sınır koruyor.

Burada küçük bir ayrıntı daha var: Kullanıcı % veya _ karakterlerini arama metnine eklerse LIKE operatörü bu karakterlere özel anlam yükleyebilir.

Bu davranış SQL Injection değildir. Ancak uygulama düz metin araması bekliyorsa geliştirici joker karakterleri ayrıca ele almalıdır.

Güvenli yazılım geliştirme yalnızca SQL Injection’ı durdurmakla bitmez. Uygulamanın iş kurallarını doğru uygulamasını da gerektirir.

SQL Injection Hakkında Sık Sorulan Sorular

SQL Injection sadece giriş ekranlarında mı ortaya çıkar?

Hayır. Arama alanları, filtreler, raporlama ekranları, API parametreleri ve veritabanına sorgu gönderen diğer işlemler SQL Injection riski taşıyabilir.

PreparedStatement SQL Injection’ı tamamen engeller mi?

PreparedStatement, doğru parametre bağlama kullanımıyla sorgunun veri değerlerinden kaynaklanan SQL Injection riskini önler. Ancak kullanıcı girdisini SQL yapısına başka bir noktada eklemek yeni bir açık oluşturabilir.

Hibernate veya JPA kullanırsam güvende olur muyum?

ORM araçları parametreli sorgu kullanımını kolaylaştırır. Ancak dinamik sorguları güvensiz biçimde oluşturursanız SQL Injection açığı yine ortaya çıkabilir.

SQL Injection ve XSS aynı şey mi?

Hayır. SQL Injection veritabanı sorgularının yapısını hedefler. Cross-Site Scripting (XSS) ise tarayıcının işlediği içerik üzerinden istemci tarafındaki güven sınırlarını hedefler.

SQL Injection önlemek için kullanıcı girdisindeki özel karakterleri engellemeli miyim?

Hayır. Genel bir özel karakter yasağı güvenilir çözüm sunmaz ve geçerli kullanıcı verilerini de reddedebilir. Parametreli sorgular, iş kurallarına uygun doğrulama ve allowlist yaklaşımı daha doğru bir savunma oluşturur.

Web Application Firewall (WAF) yeterli mi?

WAF bazı şüpheli istekleri engelleyebilir. Ancak uygulamanın güvensiz sorgu oluşturma hatasını düzeltmez. WAF’ı ek koruma katmanı olarak değerlendirin.

Sonuç: SQL Injection’a Karşı Güvenli Kodlama Alışkanlığı

SQL Injection, uygulamanın veri ile komut arasındaki sınırı kaybetmesiyle ortaya çıkar.

Geliştirici kullanıcı girdisini SQL sorgusuna doğrudan eklediğinde saldırgan sorgunun davranışını etkileyebilir.

Bu riski azaltmak için karmaşık güvenlik algoritmalarına ihtiyacımız yok. Öncelikle doğru sorgu oluşturma alışkanlığını benimsememiz gerekiyor.

Java uygulamalarında PreparedStatement kullanmak, dinamik SQL parçalarını allowlist ile sınırlandırmak, veritabanı hesaplarının yetkilerini azaltmak ve sorguları düzenli test etmek güçlü bir başlangıç sağlar.

En önemli kural oldukça basit:

SQL komutlarını uygulama belirlesin. Kullanıcılar yalnızca veri sağlasın.

Bu ayrımı koruduğunuzda SQL Injection saldırılarının temel giriş noktasını kapatmış olursunuz.

Kaynaklar

1. OWASP — SQL Injection Prevention Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
2. OWASP — Top 10:2025, A05 Injection
   https://top10.owasp.org/2025/A05_2025-Injection/
3. OWASP — Web Security Testing Guide
   https://owasp.org/www-project-web-security-testing-guide/
4. Oracle — JDBC PreparedStatement
   https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html

SQL Injection Nedir? Saldırıyı Anlamak ve Önlemek İçin Pratik Rehber yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.