What is SQL Injection?

SQL injection occurs when an application inserts untrusted input into an SQL statement instead of treating it exclusively as data. An attacker can then alter the query logic, read records, bypass checks or modify and delete data. Under unfavorable database configurations, the attack may reach beyond the database.

The vulnerability is not limited to login forms. Search fields, sorting parameters, API filters, report generators and background imports can all become entry points. Error-free or blind SQL injection uses differences in responses or timing and may remain invisible in the page content.

How can SQL injection be prevented?

• - Use parameterized queries or prepared statements for every data value.
• - Allowlist identifiers such as selectable column names; they usually cannot be bound as values.
• - Give the database account only the permissions the application requires.
• - Validate input and suppress detailed database errors as additional safeguards.

Code example: string concatenation and prepared statement

Vulnerable: Input becomes part of SQL syntax.

$email = $_GET['email'];
$sql = "SELECT id, email FROM users WHERE email = '$email'";
$user = $pdo->query($sql)->fetch();

Safe: SQL structure and data are sent separately.

$statement = $pdo->prepare(
    'SELECT id, email FROM users WHERE email = :email'
);
$statement->execute(['email' => $_GET['email']]);
$user = $statement->fetch();

Parameter binding is the actual fix. Manual escaping and blocklists of familiar characters remain fragile. Dynamic columns and sort directions cannot be bound as values and require a fixed mapping.

Are ORMs automatically safe?

ORMs bind normal values safely, but raw expressions, string-built order clauses and custom queries can reintroduce SQL injection. The decisive question is whether untrusted data ever becomes part of SQL syntax.

Which types of SQL injection exist?

In-band SQL injection exposes data or database errors in the response. UNION queries can append the output of another query. Blind SQL injection reveals facts through different responses or deliberately triggered delays. Out-of-band techniques transmit data through DNS or another external channel. The available method depends on the database, driver, query and account permissions.

A concrete example

If an application constructs SELECT * FROM users WHERE email = 'INPUT' as a string, an apostrophe may leave the data context and alter the SQL syntax. The particular payload is less important than the cause: data and command were mixed. With a prepared statement, the driver sends the query structure and parameters separately. Input remains a value even when it contains SQL characters.

Impact and reach

Consequences range from reading one table or bypassing a login to changing or deleting an entire dataset. If the database account has broad privileges, stored procedures, file access or operating system integrations can increase the impact. Segmentation and narrow database accounts limit the blast radius, but do not fix the injection itself.

How is SQL injection tested reliably?

Testing covers every data source, not only visible forms: JSON properties, headers, cookies, stored values and asynchronously processed imports may reach a query. Errors, changed result sets and repeatable timing differences are indicators, but require validation. Source review also looks for dynamic queries, raw expressions and variable column names. A safe production test uses the smallest possible proof and avoids payloads that alter real data.