Nothing unusual so far.

Now imagine entering a piece of SQL instead of an email address. What happens next depends on how the developer built the database query.

If the application inserts your input directly into its SQL statement, you might change what the database executes.

That’s the problem behind SQL Injection, often shortened to SQLi.

Although SQL Injection has been around for decades, developers still encounter it in modern web applications, REST APIs, backend services, and systems that use object-relational mapping frameworks.

The good news? Developers can prevent most SQL Injection vulnerabilities through a few reliable coding practices.

This guide explains how SQL Injection works, why it matters, and how to write safer Java database code.

What Is SQL Injection?

SQL Injection is a security vulnerability that allows an attacker to interfere with a database query by supplying specially crafted input.

The vulnerability appears when an application mixes untrusted data with SQL commands.

Consider a database query that retrieves a customer by email address:

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

This query looks for a specific customer.

But what if the application builds the query by joining SQL text with whatever the user enters?

An attacker may then influence the query’s logic instead of simply providing a value.

Depending on the application, database permissions, and query structure, SQL Injection can enable attackers to:

• Access sensitive customer information
• Read data that should remain private
• Modify or delete database records
• Bypass certain authentication checks
• Interfere with application business logic
• Disrupt database availability

Some database configurations can expose additional capabilities when the application connects with excessive privileges.

The OWASP Top 10:2025 includes SQL Injection within A05:2025 – Injection, a broader category covering injection vulnerabilities.

The important distinction is that SQL itself isn’t the problem.

The vulnerability comes from how an application handles SQL commands and external data.

How Does SQL Injection Work?

Let’s examine a small Java application.

Suppose an online store allows users to search for customer information by email address.

A developer might write the following JDBC code.

A Vulnerable Java Example

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;
    }
}

The code appears straightforward.

It creates a SQL query, executes it, and retrieves the first matching customer.

Unfortunately, one line introduces a serious security weakness:

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

The application inserts the supplied email address directly into the SQL command.

That means the value becomes part of the SQL statement’s text.

The database cannot reliably distinguish the developer’s intended query structure from SQL syntax that arrived through the user input.

What Happens When an Attacker Changes the Input?

Instead of a normal email address, consider this input:

' OR '1'='1'

When the application concatenates it into the original query, the final SQL becomes:

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

Look closely at the condition:

'1'='1'

This comparison always evaluates to true.

As a result, the database may return every row instead of looking for one customer.

The sample Java method reads only the first result, but the query itself no longer applies the intended email filter.

If other application logic treats that result as proof of identity or authorization, the consequences could become much more serious.

This example captures the central idea behind SQL Injection:

The attacker turns input data into executable SQL logic.

Why Is SQL Injection Dangerous?

SQL Injection can affect more than a single database query.

Its impact depends on the application’s architecture, the affected SQL statement, and the privileges assigned to the database connection.

Exposure of Sensitive Data

Applications often store customer details, addresses, order histories, and other valuable information.

A vulnerable query can expose data that users should never access.

Even when an attacker cannot download an entire database, accessing another customer’s records creates a security and privacy problem.

Unauthorized Data Modification

Some application accounts can create, update, or delete database records.

If an attacker exploits a suitable SQL Injection vulnerability through one of these accounts, the attacker may gain opportunities to modify business data.

For an online store, that might affect product information, customer records, or order management processes.

Application Disruption

A maliciously altered query may consume excessive database resources.

Expensive operations can reduce performance and interfere with legitimate requests.

Under certain conditions, this behavior can contribute to a denial-of-service incident.

Authentication and Authorization Risks

SQL Injection can sometimes interfere with authentication or authorization checks.

However, not every SQL Injection vulnerability gives an attacker the ability to log in as another user.

The actual outcome depends on how the application uses the query result and which permissions the database account holds.

Common Types of SQL Injection

Security professionals commonly classify SQL Injection techniques by how attackers retrieve information or observe the application’s behavior.

1. In-Band SQL Injection

In-band SQL Injection uses the same communication channel to influence the SQL query and observe its output.

Two common forms exist.

Error-Based SQL Injection

Attackers examine database error messages to learn about the underlying system.

Detailed error responses may reveal query structure, table names, or other technical information.

Union-Based SQL Injection

Attackers attempt to combine the results of different SQL queries through the UNION operator.

The technique requires compatible query structures and data types.

2. Blind SQL Injection

Some applications hide database errors and query output.

That doesn’t automatically make them immune to SQL Injection.

Attackers may still infer information by observing application behavior.

Boolean-Based Blind SQL Injection

This technique compares how an application responds to conditions that evaluate to true or false.

Time-Based Blind SQL Injection

This technique relies on differences in response times.

Since network latency and server load can introduce noise, timing observations require careful interpretation.

3. Out-of-Band SQL Injection

Out-of-band techniques attempt to use a separate communication channel to retrieve information.

These attacks depend on particular database capabilities, network access, and configuration choices.

Not every database environment supports the conditions they require.

4. Second-Order SQL Injection

Second-order SQL Injection often surprises developers.

An application first stores untrusted input in its database.

Later, another part of the application retrieves that stored value and inserts it into a new SQL query without proper parameter binding.

The vulnerability appears during the second operation rather than the original request.

This illustrates an important security principle: data doesn’t automatically become trustworthy because it came from your own database.

How to Prevent SQL Injection

The most effective approach starts with one rule:

Keep SQL commands separate from data values.

OWASP recommends parameterized queries as a primary defense.

Let’s examine what that means in practice.

1. Use Prepared Statements and Parameterized Queries

Java provides the PreparedStatement interface through JDBC.

Instead of embedding a value inside SQL text, we define the SQL statement and bind the value separately.

Here’s a safer version of our customer lookup.

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;
        }
    }
}

Two details matter here.

First, the ? placeholder represents a data value.

Second, setString() binds the supplied email address to that placeholder.

The JDBC driver handles the value through the database parameter-binding mechanism.

Even if someone enters:

' OR '1'='1'

the database treats that input as a string value to search for rather than additional SQL logic.

Why Do Prepared Statements Work?

Prepared statements establish a boundary between the SQL statement’s structure and its data values.

The application defines the query.

The user supplies the values.

That difference prevents data-bound input from changing the query’s intended syntax.

It also handles legitimate values containing special characters, such as a customer’s name with an apostrophe.

One limitation matters, though: prepared statements protect the values you bind. They cannot protect SQL fragments that you still construct through unsafe concatenation.

2. Use Allow-Lists for Dynamic Query Structure

Parameterized queries work for data values, but they don’t replace SQL identifiers or keywords.

For example, a JDBC ? placeholder cannot represent a column name in an ORDER BY clause.

Suppose your online store allows customers to sort products by price or name.

Avoid this approach:

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

Here, the application inserts untrusted input into the SQL statement’s structure.

Instead, define which options the application supports.

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

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

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

The application now controls the SQL identifiers and keywords.

Users can request only the choices the developer explicitly supports.

Continue using prepared statements for the query’s ordinary data values.

3. Validate Input According to Business Rules

Input validation helps applications reject unexpected values.

For example, an application can require a product identifier to contain a positive integer or limit the length of a search term.

Those checks improve reliability and reduce unnecessary processing.

However, input validation alone doesn’t prevent SQL Injection.

Blocking quotation marks or maintaining a blacklist of suspicious SQL keywords cannot reliably address every SQL dialect and query context.

Use validation for business rules and parameter binding for database query safety.

4. Apply the Principle of Least Privilege

Database accounts should have only the permissions their applications actually need.

For example, a service that reads product information shouldn’t require permission to modify every customer record.

A PostgreSQL administrator could restrict table permissions with statements such as:

REVOKE ALL ON TABLE products
FROM product_reader;

GRANT SELECT ON TABLE products
TO product_reader;

These statements control permissions on the specified table. A production security review must also consider role inheritance, schema permissions, and access to other database objects.

Least privilege doesn’t remove a SQL Injection vulnerability.

Instead, it reduces the potential damage if an attacker successfully exploits one.

For larger architectures, consider different database roles for services with different responsibilities.

A reporting service and an order-processing service rarely need identical database privileges.

5. Don’t Assume Your ORM Makes Every Query Safe

Developers often use Hibernate, JPA, or similar frameworks to avoid writing repetitive SQL code.

These frameworks support parameterized query APIs, but developers can still introduce vulnerabilities through unsafe query construction.

Consider this JPQL example:

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

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

The application still inserts untrusted input into the query text.

A better approach uses a named parameter.

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

query.setParameter("email", email);

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

Here, the ORM treats the email value as a parameter.

Review dynamically constructed JPQL, HQL, native SQL, and sorting expressions with the same attention you give to ordinary JDBC queries.

6. Review Stored Procedures Carefully

Stored procedures can help organize database logic.

However, they don’t automatically eliminate SQL Injection.

A procedure that constructs dynamic SQL by concatenating untrusted values can create the same vulnerability as application-level string concatenation.

Use bound arguments when calling procedures.

Inside the procedure, prefer static SQL or parameterized dynamic SQL.

When a procedure needs a dynamic identifier, restrict the selection to trusted, application-approved choices.

7. Handle Database Errors and Logs Safely

Database error messages help developers diagnose problems.

But detailed SQL errors can reveal useful information to attackers.

Production applications should avoid returning raw database exceptions to clients.

Keep technical error details in protected logs, and provide clients with appropriate generic error responses.

Make sure your logging strategy also protects sensitive information.

Passwords, authentication tokens, and private customer data shouldn’t appear in ordinary diagnostic logs.

How Can Developers Test for SQL Injection?

You should test only applications and environments you own or have explicit authorization to assess.

Start with code review and repeatable automated checks.

Review Query Construction

Look for places where the application builds SQL statements dynamically.

Pay particular attention to:

• String concatenation inside SQL queries
• Dynamic JDBC Statement execution
• Native SQL constructed through ORM frameworks
• Dynamic JPQL or HQL expressions
• Stored procedures that assemble SQL text
• User-controlled sorting fields and identifiers

The presence of Statement alone doesn’t prove a vulnerability. The risk arises when untrusted data can modify SQL syntax.

Combine SAST and DAST

Static Application Security Testing (SAST) tools inspect source code for potential vulnerabilities.

Dynamic Application Security Testing (DAST) tools examine a running application’s behavior.

Tools such as OWASP ZAP can support an authorized testing process.

Neither category guarantees complete coverage.

Use automated testing alongside code review and carefully designed regression tests.

Write a Java Regression Test

A simple JUnit 5 test can verify that your repository treats suspicious input as ordinary data.

@Test
void shouldNotInterpretInputAsSql()
        throws SQLException {

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

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

    assertNull(customer);
}

For this test, use an isolated database with known records and no customer whose email equals the supplied test string.

You can strengthen the test by inserting a legitimate customer first and verifying that the suspicious input doesn’t return that record.

This doesn’t replace broader security testing.

It does, however, help prevent a previously corrected vulnerability from returning during a future code change.

A Real-World Example: Securing an E-Commerce Product Search

An e-commerce application exposes many database-driven operations.

Product searches, price filters, order histories, customer profiles, and administrative reports all deserve attention.

Let’s implement a simple product search using Java and JDBC.

The method accepts a keyword and a maximum price.

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;
}

This example binds both user-controlled values.

The first parameter searches for products containing the requested keyword.

The second parameter limits the maximum price.

Notice that the code adds % characters to the Java string before binding it.

That’s safe from SQL Injection because the application constructs a parameter value rather than adding SQL syntax to the query.

There is one additional detail worth understanding.

SQL LIKE treats % and _ as wildcard characters. If your application expects literal text matching, you should handle those characters according to your database’s escaping rules.

That’s a search-behavior concern rather than an SQL Injection vulnerability, but it demonstrates why secure code must also follow the application’s business requirements.

Frequently Asked Questions About SQL Injection

Is SQL Injection still a problem in modern applications?

Yes. Modern frameworks provide safer database APIs, but developers can still introduce SQL Injection vulnerabilities when they concatenate untrusted values into query text.

Does SQL Injection affect only login forms?

No. Search fields, filters, reports, API parameters, and other database-driven operations may expose vulnerable queries.

Can prepared statements completely prevent SQL Injection?

Correctly parameterized data values cannot change the SQL statement’s structure. However, developers can still create vulnerabilities by constructing other query fragments from untrusted input.

Does Hibernate prevent SQL Injection automatically?

No. Hibernate supports secure parameter binding, but unsafe dynamically constructed HQL, JPQL, or native SQL can introduce vulnerabilities.

Should I remove special characters from user input?

Not as a general SQL Injection defense. Legitimate values may contain apostrophes and other special characters. Use parameter binding instead of relying on character filtering.

Can a Web Application Firewall stop SQL Injection?

A WAF may detect or block some malicious requests, but it cannot guarantee protection and doesn’t fix the underlying code defect. Treat it as an additional security layer.

What’s the difference between SQL Injection and XSS?

SQL Injection targets the structure of database queries. Cross-Site Scripting (XSS) targets how browsers interpret untrusted content. Both involve trust boundaries, but they affect different execution contexts.

Final Thoughts: Make Safe Queries Your Default

SQL Injection becomes possible when an application allows external data to change the structure of a database query.

You don’t need an elaborate security system to address the core problem.

Start by writing parameterized queries. Use explicit allow-lists when users need to influence query structure. Limit database privileges and include security checks in your development workflow.

If you’re writing Java, make PreparedStatement your default choice for JDBC queries that include variable data.

If you’re using an ORM, learn how its parameter-binding APIs work and avoid unsafe dynamic query construction.

Most importantly, keep one principle in mind:

Your application defines the SQL. Your users provide the data.

That separation is the foundation of SQL Injection prevention.

References and Further Reading

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 — Using Prepared Statements
   https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html

SQL Injection: A Friendly Guide to Understanding the Threat yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

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ı.