Vulnerability guide
SQL injection vulnerability
Learn what SQL injection is, how SQLi attacks work, where they appear in web applications, and how to prevent them with parameterized queries, safe database access, and least privilege.
What SQL injection is
SQL injection, often shortened to SQLi, happens when an application lets untrusted input change the structure or intent of a database query. Instead of treating a value as plain data, the application accidentally lets that value participate in the SQL command itself.
The root problem is unsafe query construction. A search term, account identifier, API filter, cookie, or stored profile field may look harmless in the interface, but it becomes dangerous if the backend joins it directly into SQL text.
How SQL injection works
Databases interpret SQL as instructions. Applications are supposed to send a fixed instruction shape and bind user values separately. SQL injection appears when those two things are blended together, so user-controlled text can influence the query parser.
const sql = "SELECT * FROM users WHERE email = '" + email + "'"
const user = await db.query(sql)
The query text changes when the value changes. Escaping mistakes, unusual encodings, or one forgotten path can turn this into a vulnerability.
const user = await db.query(
'SELECT * FROM users WHERE email = ?',
[email]
)
The SQL structure stays fixed and the email is passed as data. This is the security property that makes prepared statements and parameterized queries so important.
Why SQL injection matters
{ "SQLi can move from a single vulnerable input to direct business impact because the database often holds the application state that matters most": "identities, permissions, transactions, secrets, customer records, operational history, and audit evidence." }
Confidentiality loss
Attackers may read customer data, internal records, password hashes, tokens, or business information that should never leave the database.
Integrity damage
Unsafe queries can allow unauthorized changes to records, prices, permissions, audit trails, or application settings.
Account takeover
When authentication queries are vulnerable, attackers may bypass login logic or pivot from exposed data into user accounts.
Availability risk
Expensive queries, database errors, or destructive operations can degrade service, break workflows, or require emergency restoration.
Common forms of SQL injection
SQL injection is not one technique. It is a family of query-manipulation flaws that vary by database engine, application behavior, error handling, network access, and the amount of feedback an attacker can observe.
| Form | What to understand |
|---|---|
| Error-based SQL injection | The application exposes database errors that reveal query structure, table names, column names, or other useful details. |
| Union-based SQL injection | An attacker tries to combine the application query with another result set so hidden data is returned in the normal response. |
| Boolean blind SQL injection | The page does not show database details, but true or false conditions change the response enough to infer information. |
| Time-based blind SQL injection | The response delay becomes the signal when visible output does not change. This often appears in slower, harder-to-triage cases. |
| Out-of-band SQL injection | The database is induced to make a separate network interaction, which can confirm exploitation when direct responses are limited. |
| Second-order SQL injection | Malicious input is stored safely enough at first, then later reused unsafely inside another database query. |
Where SQL injection appears
Teams often check visible forms first, but SQLi can hide anywhere request or stored data reaches a query. Treat every boundary as a possible source until the data access path proves otherwise.
- Login, registration, password reset, and account lookup forms.
- Search boxes, sorting options, filters, pagination, and report builders.
- URL parameters such as product IDs, invoice IDs, tenant IDs, and tracking references.
- API request bodies, GraphQL variables, JSON filters, and mobile app endpoints.
- Cookies, custom headers, referrer values, and user agent values that are later queried.
- Admin tools, data export screens, import jobs, and internal support dashboards.
- Stored profile fields, comments, tickets, or integration payloads later used in dynamic SQL.
How to prevent SQL injection
{ "SQL injection prevention should be built into the data access layer instead of handled as a last-minute filter": { " The strongest pattern is simple": "keep SQL code and external values separate, then reduce the impact if something still goes wrong." } }
Use parameterized queries by default
Prepared statements keep SQL structure separate from user-supplied values. This is the primary control recommended by OWASP and secure-by-design guidance.
Treat ORMs as helpers, not guarantees
ORMs reduce direct SQL writing, but raw query builders, string interpolation, dynamic filters, and unsafe escape hatches can still reintroduce SQLi.
Allow-list dynamic identifiers
Values can be parameterized. Table names, column names, and sort directions should be selected from explicit server-side allow-lists.
Run databases with least privilege
Application accounts should have only the permissions they need. Separate read, write, migration, and admin roles to reduce blast radius.
Handle errors safely
Return generic user-facing errors, keep detailed traces in restricted logs, and avoid exposing query fragments or database metadata.
Use WAF rules as defense in depth
A WAF can block common probes and add visibility, but it should not replace fixing unsafe query construction in application code.
Detection and response
Testing must stay authorized, scoped, and respectful of the systems involved. Good detection combines code review, automated tooling, runtime telemetry, and retesting after remediation.
- 1
Map input to database behavior
Inventory every place user-controlled data reaches a query: route params, request bodies, headers, background jobs, imports, and stored fields.
- 2
Review code and query builders
Look for string concatenation, template literals, raw SQL helpers, dynamic ORDER BY clauses, and manual escaping around database calls.
- 3
Run authorized testing
Use SAST, DAST, dependency checks, and manual review in environments you own or are explicitly authorized to test.
- 4
Watch runtime signals
Monitor database errors, unusual query timings, repeated probing patterns, WAF events, and unexpected changes in authentication or search flows.
- 5
Patch and retest
Replace unsafe query construction, add tests for the vulnerable path, rotate exposed secrets if needed, and retest with the original evidence.
Developer checklist
Use this checklist when reviewing a feature, API endpoint, migration, reporting workflow, or database helper before it reaches production.
- No user input is concatenated into SQL strings.
- Every value in a WHERE, INSERT, UPDATE, or DELETE statement is bound as a parameter.
- Dynamic table names, column names, and sort directions come from server-side allow-lists.
- Raw SQL helpers require review and are covered by tests.
- Database users have limited privileges and cannot perform unnecessary administrative actions.
- Detailed database errors are logged privately, not shown to users.
- Security tests cover authentication, search, filters, exports, imports, and admin workflows.
- Findings are retested after remediation and tracked to closure.
SQL injection FAQ
What is SQL injection?
SQL injection is a vulnerability where untrusted input becomes part of a database query instead of being handled as data. If the application builds SQL unsafely, an attacker may alter the meaning of the query.
Is SQL injection still common?
Yes. SQL injection has been known for decades, but it still appears when applications use raw SQL, unsafe query builders, dynamic filters, legacy code, or manual escaping.
What is the best way to prevent SQL injection?
Use prepared statements or parameterized queries for values, allow-list dynamic identifiers, avoid unsafe raw SQL, run with least database privilege, and test the database access layer continuously.
Can a web application firewall stop SQL injection?
A WAF can block many common probes and provide useful logs, but it is a defense-in-depth control. The durable fix is to remove unsafe query construction from the application.
References and further reading
This guide summarizes established defensive guidance and rewrites the concepts in Splorix's own wording. Use the original references for deeper technical detail and secure development policy.