Injection Testing

Why it matters

Injection has sat among the OWASP Top 10 web application security risks for years, because the mistake is easy to make and the consequences are severe: one unparameterised query can expose every row in a table, let someone bypass a login, or corrupt data. The defect is invisible in normal use — the feature works perfectly for ordinary input — so it survives until someone sends input the developer did not expect.

For a tester, injection is high-value work: the probes are cheap, they follow a repeatable pattern across every input that reaches an interpreter, and a confirmed finding is usually fixed quickly because the remedy is well understood. Finding one injection point before release is far cheaper than a breach in production.

Where injection happens

Every injection has the same shape: data from the user is combined with a command for some interpreter, and the interpreter cannot tell which part was meant to be data. Wherever the application builds a command out of text, there is a candidate — and the interpreter does not have to be a database.

• SQL injection: input reaches a database query. A lone single quote ' is a metacharacter — a character with a special meaning to the interpreter, here the end of a text value — and it often provokes a database error, the first sign the input is being parsed as SQL.
• OS command injection: input reaches a shell command, for example a file name the application inserts into a command it runs. Shell metacharacters such as ;, | and & can change what runs.
• LDAP, XPath and NoSQL injection: input reaches a directory filter, an XML query or a document-database query, each with its own syntax and special characters.
• Server-side template injection: input reaches a template engine that evaluates expressions, which can turn a profile name into executed code.
• Reach matters more than the field name: a value from a URL, a header, a cookie or an uploaded file can travel to an interpreter just as a form field can.

Try it: Test Scenario Generator

Probing safely

Test only systems you own or have written permission to test, and prefer the mildest input that answers the question. The goal is to learn whether input is parsed as code, not to cause damage, so you never use payloads that delete, change or read out data.

The safest first probe is a single metacharacter on its own. If a ' produces a database error, a stack trace or a changed result while a normal value does not, the input is reaching the interpreter unprotected — enough to raise a defect. You confirm with one harmless comparison and go no further: two quotes '', which SQL reads as one literal quote inside a text value, should make the error disappear; or a normal value with an always-true condition joined by AND should return the usual result, while the same value with an always-false condition returns nothing.

• Use metacharacters as signals: ', ", ;, -- for SQL; ;, |, & for shells; *, (, ) for LDAP.
• Watch the differential: a database error, a changed response, a longer delay or a different row count between a benign and a crafted input is the evidence.
• Test every channel, including inputs hidden by the UI, because validation on the screen does not protect the server.
• Never run destructive or data-reading exploit chains; stop at the proof that input is interpreted.

Try it: Special Character Dataset Generator Try it: Negative Test Generator

Worked example: the fix is parameterised queries

Consider a customer lookup that finds users by email. The vulnerable version builds the query by joining strings, so the input lands inside the SQL text. The fix is a parameterised query (also called a prepared statement): the query text is fixed and the input is sent to the database separately, as a value that can never change the query's structure.

Input validation and escaping help, but they are not the fix for injection: the fix is the SQL row of the previous lesson's table of output contexts, a parameterised query. Valid data legitimately contains metacharacters: the surname O'Brien has an apostrophe, so validation cannot reject them. Escaping those characters is only a last resort for the server-side interpreters this lesson covers: each interpreter has its own special characters, and one that is missed reopens the hole. Keeping data and code separate with parameterisation is what actually closes it. A part of the query that cannot be bound, such as a column name chosen for sorting, must be checked against a fixed allow-list of names, and least-privilege database accounts limit the damage if an injection point is missed.

-- Vulnerable: input is pasted into the SQL text, so it can act as code
sql = "SELECT * FROM users WHERE email = '" + input + "'"

  input = ben@shop.test   ->  ... WHERE email = 'ben@shop.test'
  input = ' OR '1'='1     ->  ... WHERE email = '' OR '1'='1'   (logic changed)

-- Safe: the query text is fixed; input is bound as a separate value
sql    = "SELECT * FROM users WHERE email = ?"
params = [ input ]

  input = ' OR '1'='1     ->  compared as text; matches no row

Try it: SQL Query Validator

What to report

A good injection report lets a developer reproduce and fix the defect without guessing. Name the exact endpoint and parameter, the input you sent, the response that proves the input was interpreted, and the response for a benign input as a control. State the impact in terms of what the interpreter governs, and recommend the fix.

• Location: the URL or screen, the HTTP method, and the exact parameter, field, header or cookie.
• Input and evidence: the precise characters you sent and the observed result — the error text, the differential behaviour or the status code — with a benign input alongside for comparison.
• Impact and severity: what the affected interpreter controls (authentication, a data table, a shell), rated with your team's severity scale.
• Fix: parameterised queries or the interpreter's safe API, with validation and least privilege as defence in depth.
• Scope: note that you tested only the authorised system and stopped at proof, so the reader knows no data was touched.

Try it: API Request Builder

Frequently asked questions

References

• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Cheat Sheet Series: SQL Injection PreventionOWASP FoundationParameterised queries, stored procedures used safely, allow-list validation and least privilege — the defences a database test should confirm.
• OWASP Cheat Sheet Series: Injection PreventionOWASP FoundationPreventing SQL, OS-command and other injection through parameterisation, validation and escaping.