Cybersecurity glossary
What is SQL Injection (SQLi)?
Learn what SQL injection (SQLi) is, how untrusted input becomes database queries, types like blind and time-based SQLi, and how parameterized queries prevent injection.
Definition
SQL Injection (SQLi) is a vulnerability in which untrusted input is interpreted as part of a SQL statement, allowing attackers to alter query logic to read, modify, or destroy database data—and sometimes execute commands on the database server.
Why SQL injection remains critical
Databases hold accounts, payments, health records, and secrets. When applications build SQL by gluing strings together, attackers can reshape those statements. SQL Injection (SQLi) has powered decades of breaches and still appears in modern APIs and ORMs when used unsafely.
For hands-on exploitation detail, see Splorix’s SQL injection vulnerability guide. This entry defines the concept and prevention principles.
How SQLi works
Application builds a SQL string
User input is concatenated into WHERE clauses, ORDER BY, or identifiers.
Attacker supplies SQL syntax
Quotes, comments, UNION, and boolean logic alter the intended statement.
Database executes attacker logic
The DB engine cannot tell trusted SQL from injected fragments.
Impact materializes
Data disclosure, authentication bypass, corruption, or further compromise.
Common SQLi varieties
In-band / classic
Results or errors return directly in the HTTP response.
Blind
No direct data output; attackers infer truth via boolean differences.
Time-based
Deliberate SLEEP/WAITFOR delays encode bits of information.
Second-order
Payloads stored safely, then later concatenated into unsafe queries.
Prevention that works
| Control | Notes |
|---|---|
| Parameterized queries | Bind values separately from SQL structure |
| Safe ORM usage | Avoid raw SQL string interpolation in ORM helpers |
| Least privilege DB users | App accounts should not be DBA-equivalent |
| Allowlist dynamic identifiers | Table/column names cannot be parameterized—allowlist only |
| WAF / CRS rules | Defense in depth, not a substitute for parameterization |
- Use prepared statements or equivalent binding for every query with untrusted input.
- Ban string concatenation for SQL in code review standards.
- Allowlist any dynamic ORDER BY / column names.
- Grant database roles only the permissions each service needs.
- Disable dangerous DB features (xp_cmdshell, etc.) where unused.
- Log and alert on unusual query errors and high-latency patterns.
- Include SQLi tests in CI for login, search, and filter endpoints.
- Treat confirmed SQLi as critical until proven limited in impact.
The practical takeaway
SQL injection happens when user data becomes SQL syntax. Parameterize queries, constrain privileges, and never rely on filters alone.
If your code builds SQL with + or string templates and user input, fix that path before anything else.
Related security terms
SQL Injection vulnerability guide
Splorix deep dive on SQLi exploitation and remediation.
Blind SQL Injection
SQLi when results are not returned directly in the page.
Time-Based SQL Injection
Inferring data through intentional query delays.
NoSQL Injection
Analogous injection against document and key-value stores.
Frequently asked questions
What is SQL injection in simple terms?
Attackers type database commands into form fields or URLs so the application runs their SQL instead of only the intended query.
Why is SQLi still common?
Legacy string concatenation, unsafe ORMs misuse, dynamic query builders, and second-order injection in older codebases keep it alive.
What is the primary defense?
Parameterized queries / prepared statements (or equivalent ORM binding) so user data never becomes SQL syntax.
Does input validation stop SQLi?
It helps as defense in depth but is not sufficient alone. Parameterization is the reliable control.
Can a WAF replace secure coding?
No. WAFs may block known payloads but miss novel encodings. Fix the query construction.
What can attackers do with SQLi?
Bypass login, dump tables, modify data, escalate database privileges, and sometimes reach the OS via database features.
How is SQLi different from XSS?
SQLi targets the database query interpreter; XSS targets the browser. Both are injection flaws in different interpreters.
References
Explore authoritative guidance and frameworks related to sql injection (sqli).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.