Quick answer: SQL injection (SQLi) is when input from a user mixes into a database query and changes the query's logic. By typing special characters into a search box or a URL parameter, an attacker can run their own commands against the database on behalf of the application: pulling the entire user table, retrieving password hashes, even deleting data. Despite being known for decades, it remains one of the most common critical flaws and sits under Injection in the OWASP Top 10. The single definitive solution is parameterized queries (prepared statements): input is never pasted into the query text, it is sent as a separate parameter. Trying to clean input by hand is an unreliable patch, not the real fix.

The oldest and most dangerous flaw in a web application is still standing: SQL injection. More than twenty years have passed since it was first described, yet a significant share of data breaches still begin this way. The reason is not technical but cultural: even though the correct defense is simple and well known, incorrectly written code is still produced. This article explains how SQL injection works and its definitive solution.

How SQL injection works

Imagine an application building a query to check a username, pasting the input directly into the text:

SELECT * FROM users WHERE name = 'input' AND password = 'input2'

If the user types this into the name field instead of normal text:

' OR '1'='1

The query becomes:

SELECT * FROM users WHERE name = '' OR '1'='1' AND password = ''

Because '1'='1' is always true, the condition is satisfied and the attacker can log in without knowing a password. This is the simplest example. Real attacks use far more complex input to dump entire tables, join other tables (UNION) or learn the database version.

The root of the problem is a single error: data (user input) and code (the SQL command) mix into the same text string. The database cannot tell where the command ends and the data begins.

Types of SQL injection

Type How it works Distinguishing aspect
Classic (in band) Result appears directly on the page Easiest to detect and exploit
Blind Result is invisible, inferred from true/false behavior Slow but effective
Time based blind A delay is injected, read from response time Works with no output at all
Error based Information leaks from database error messages Very productive if verbose errors are exposed
Out of band Data is exfiltrated via DNS or HTTP Used in isolated environments

This variety matters because "I see no error on the page, so I am safe" is wrong. Blind and time based techniques work with no visible sign.

The definitive solution: parameterized queries

The only real solution to SQL injection is separating data from code. This is done with parameterized queries (prepared statements). The query template and the data are sent separately, and the database never interprets the data as a command.

Wrong (input pasted into the text):

"SELECT * FROM users WHERE name = '" + input + "'"

Right (input sent as a parameter):

"SELECT * FROM users WHERE name = ?"   // then input as a separate parameter

In this approach, whatever the attacker types is treated only as a value and can never change the query's structure. Every modern database library and ORM supports this. A correctly used ORM largely protects against SQL injection.

Why hand cleaning is not enough

A common mistake is trying to manually strip dangerous characters (such as quotes) from input. This is unreliable because:

  • Different databases have different escaping rules.
  • Character encoding differences can bypass the filter.
  • Numeric fields do not require quotes, so such filters miss them.

Hand cleaning can be a defense layer but is never sufficient alone. The real solution is the parameterized query.

Defense in depth

The parameterized query is the primary defense, but critical systems need layered protection:

  • Least privilege. The application's database user should be authorized only for the operations it needs. Even if a flaw is found, the damage stays limited.
  • Input validation. Reject input that does not match the expected format up front. This does not replace parameterized queries but adds a layer.
  • Web Application Firewall (WAF). Catches known injection patterns. It helps, it is not the root fix, and it can be bypassed.
  • Hiding error messages. Verbose database errors guide the attacker. Show generic errors in production.
  • Logging and monitoring. Anomalous query patterns should be watched. This is part of the SIEM and SOC approach.

SQL injection is the best known example of the OWASP Top 10 Injection category; for the wider framework see our OWASP Top 10 guide. For another flaw in the same category, see our XSS article.

Is your application safe, and how do you verify

Even if the code looks secure, a single overlooked query opens the whole system. The only reliable way to verify is testing:

  • Code review. Confirm all database access is parameterized.
  • Static analysis. Automated tools flag concatenated queries.
  • Authorized penetration testing. Being tried like a real attacker reveals the remaining flaw. See our article on the penetration test process.

Frequently asked questions

Why is SQL injection still common? Despite the known solution, incorrect code keeps being written. Legacy systems, hastily written code and lack of training are the main reasons.

I use an ORM, am I safe? Largely, but you can fall into the same mistake when using the ORM's raw query feature. Using the ORM correctly is essential.

Will a WAF protect me? Partly. A WAF catches known patterns but can be bypassed. The root fix is the parameterized query, the WAF is an added layer.

Is blind SQL injection dangerous? Yes. Even without visible output, an attacker can extract data one piece at a time from true/false responses or delays.

Are numeric fields safe? No. Because numeric parameters do not require quotes, some filters miss them. The parameterized query is essential here too.

Can data be deleted with SQL injection? If the database user has the privilege, yes. This is why the principle of least privilege is critical.

Sources

To measure whether your application is genuinely resilient against SQL injection, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing, secure code review and developer training.