Innomerc Choose your depth. Learn at your own pace.
Understand it
SQL injection happens when untrusted input is interpreted as part of a database instruction rather than only as data. A search box should provide a search value, not control the structure of the query that the application executes.
In the fictional catalog, the unsafe path builds a query by joining text. The safer path sends a fixed statement and a separate value. The visual represents input symbolically; it does not provide an executable attack against a database.
Under the hood
Parameterized queries let the database driver distinguish statement structure from bound values. They are the primary defense for values. Dynamic identifiers such as table names or sort directions usually cannot be bound in the same way and need strict allowlisted selection.
Escaping rules are database- and context-dependent and should not replace parameterization. An ORM can still become unsafe when code drops into raw query construction. Stored procedures can also be vulnerable if they construct dynamic SQL unsafely.
Practitioner perspective
Review data flows from request parameters, imported files and stored values into query construction. A value saved earlier can become unsafe when used in a later dynamic query. Test with synthetic data and an explicitly authorized scope.
Use database permissions to reduce impact: the application account should not have unnecessary administrative privileges. Investigate unusual query errors and access patterns, while avoiding logging secrets or entire sensitive queries. Error suppression alone does not remove injection.
Watch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Explore the system
Search input
An untrusted search value reaches the application.
Read every step without animation
Unsafe concatenation
- Search input. An untrusted search value reaches the application.
- String assembly. The application joins input directly into query text.
- Changed structure. Input is interpreted as part of the instruction.
- Unexpected access. The query may operate outside the intended search.
The data/instruction boundary was lost.
Parameterized query
- Search input. The same untrusted value reaches the application.
- Fixed statement. The application prepares a statement with a value placeholder.
- Bound value. The driver sends the input as data for that placeholder.
- Intended query. The input does not alter the statement structure.
Separate query structure from untrusted values.
Explore deeper: additional experiment
Where does user input go?
The SQL structure is fixed before the value is bound. Syntax characters in a value do not become SQL instructions at this parameter boundary. Dynamic table and column names require separate allowlisting.
A local teaching model with fictional inputs. It does not test a live system.
Attack view
The input in this model changes the intended query structure. The failure occurs before execution, at the boundary where application data becomes database syntax.
Defender view
- Use parameterized queries for values.
- Allowlist unavoidable dynamic identifiers and avoid unnecessary raw SQL.
- Restrict database account privileges and handle errors without exposing internals.
Common mistakes
- An ORM is not safe when raw SQL is assembled unsafely.
- Input filtering alone is not a universal SQL injection defense.
Check your understanding
Active recall: explain this idea in 30 seconds
SQL injection happens when untrusted input is interpreted as part of a database instruction rather than only as data. A search box should provide a search value, not control the structure of the query that the application executes.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Read the editorial policy.