What injection is

Every injection bug in the world, SQL injection, cross-site scripting, command injection, template injection, is the same mistake wearing different clothes. Learn the shape once, in this lesson, and you will recognise the whole family on sight.

The one shape: data that becomes code#

Applications constantly build strings that mix two things: fixed parts the developer wrote, and variable parts that came from you. A database query is a string. An HTML page is a string. A shell command is a string. In each case there is a template, "look up the user named ___", and your input is supposed to drop into the blank as plain data.

Injection happens when your input does not stay in the blank. If the surrounding string is not built carefully, a well-chosen input can break out of the data slot and be read as part of the code. Consider a login that builds:

SELECT * FROM users WHERE name = '[your input]'

Send the name alice and it looks up Alice. Send the name alice' OR '1'='1 and the string becomes:

SELECT * FROM users WHERE name = 'alice' OR '1'='1'

Your quote closed the string early, and everything after it, OR '1'='1': is now SQL the database executes, not a name it searches for. '1'='1' is always true, so the query returns every user. You did not find a password bug; you changed the query itself. That is injection.

Why it keeps happening#

Because building strings by pasting values together is the obvious, easy way to write code, and it is wrong in a way that works perfectly until someone sends a quote. The application looks finished. It serves normal users flawlessly. The flaw only appears when input contains the special characters that mean something to the interpreter on the other end, a quote to SQL, an angle bracket to HTML, a semicolon to a shell. Every one of those interpreters has "special" characters, and injection is what happens when the app lets your special characters reach the interpreter with their power intact.

The members of the family#

Same shape, different interpreter:

• SQL injection: your input reaches a database query. You can read, change, or destroy the data, and sometimes run commands on the server. Lessons 2–4.
• Cross-site scripting (XSS): your input reaches an HTML page, and your <script> runs in a victim's browser. Lessons 5–7.
• Command injection: your input reaches a shell command, so you run programs on the server. (Covered in the Server-side path.)
• Template injection (SSTI): your input reaches a template engine that evaluates it, often leading to code execution. (Also server-side path.)

Different targets, one instinct: where does my input go, and does it stay data?

The fix, so you recognise a safe app#

Knowing the fix helps you spot the bug. The correct way to mix code and data is to keep them separate at the interpreter level, not to try to clean the input by hand. For databases that means parameterised queries (also called prepared statements): the query template and the values travel separately, and the database treats the value as data no matter what characters it contains. For HTML it means context-aware output encoding: before printing your input into a page, turn < into < so the browser shows it as text instead of running it. An app that builds queries or pages by string concatenation, and tries to "sanitise" by stripping quotes or blocking words, is fragile, those blocklists are routinely bypassed, and the next lessons show how.

How you will hunt it#

The method is consistent across the whole family:

1. Find the input reaching an interpreter. Any parameter, field, header, or path segment that ends up in a query, a command, or the page.
2. Send a character that is special to that interpreter and watch for a reaction, a quote to SQL (an error, or a change in results), an angle bracket to HTML (does it appear as a tag?).
3. If it reacts, craft a payload that proves you changed the code, not just the data.
4. Confirm impact honestly and stop at the proof.

Keep it honest and in scope#

Injection is the most destructive bug class to test carelessly. A SQL payload can delete rows; a stored XSS lands on real users. So this is a hard scope line: only against targets you are authorised to test. On this Academy's labs, experiment freely. On a real engagement, prove the vulnerability with the gentlest payload that demonstrates it (a query that reads one harmless value, an alert that proves script execution) and never a destructive one.

Where this goes next#

You have the shape. The next three lessons make it concrete with the highest-impact injection there is: SQL injection, starting with how to find it by making a database react to a single quote.