Bir web uygulamasının giriş ekranına kullanıcı adınızı yazdığınızı düşünün. Uygulama bu bilgiyi veritabanına gönderiyor ve hesabınızı arıyor. Buraya kadar her şey normal.
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 = '[email protected]';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
Statementile dinamik sorgu çalıştırma- Native SQL ve dinamik JPQL/HQL oluşturma
- Stored procedure içinde dinamik SQL kullanımı
ORDER BYve 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
- OWASP — SQL Injection Prevention Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - OWASP — Top 10:2025, A05 Injection
https://top10.owasp.org/2025/A05_2025-Injection/ - OWASP — Web Security Testing Guide
https://owasp.org/www-project-web-security-testing-guide/ - Oracle — JDBC PreparedStatement
https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html