One root cause: data and code in one string

An interpreter reads text and turns it into actions. Your database parses SQL. The browser parses HTML and runs JavaScript. A shell parses a command line. Each one has special characters that change meaning: a quote ends a SQL string, an angle bracket starts an HTML tag, a semicolon or a space separates shell words.

Injection happens when your code builds one string out of trusted code and untrusted input, then hands that string to an interpreter. The interpreter can't see which characters came from you and which came from the user. If the input contains characters that are special to that interpreter, they change what the code means.

The harmless version shows up all the time. A customer called O'Brien searches for his own name, the apostrophe closes the SQL string early, and the database rejects the query with a syntax error. That error is a gift: it tells you the input is being parsed as code. Someone who chooses their input with care can do much more than cause an error, because the same gap lets them change the query's meaning, for example to remove the filter that keeps each shop to its own rows.

OWASP lists injection in the Top 10 of both 2021 (as A03, where cross-site scripting was folded into it) and 2025. The lasting fixes all follow one idea: send code and data through separate channels, so data can never be parsed as code. Escaping special characters by hand, or deleting the dangerous ones, is the weaker fallback for when no separate channel exists.

SQL injection: the fix that lasts

Here is the "before", the kind of code you will meet in reviews. It is short and it works for most searches, which is why it survives:

// Before: the term and the sort are pasted into the SQL text
const sql = `SELECT id, invoice_no, total_cents FROM invoice
  WHERE shop_id = ${shopId} AND customer_name ILIKE '%${term}%'
  ORDER BY ${sort}`;
const { rows } = await pool.query(sql);

Three inputs flow into the text: the shop ID, the search term and the sort. Each one is a way to change the query. The lasting fix is a parameterised query, also called a prepared statement. In node-postgres you pass the text with $1, $2 placeholders and an array of values. The driver sends them to Postgres separately: the server parses and plans the text first, then binds the values into the slots. A value can contain quotes, percent signs or SQL keywords and it will still be one string compared against customer_name.

const SORTS = new Map([
  ['newest', 'issued_on DESC'],
  ['oldest', 'issued_on ASC'],
  ['total', 'total_cents DESC'],
]);
const orderBy = SORTS.get(sort) ?? SORTS.get('newest');  // identifiers come from our code

const { rows } = await pool.query({
  text: `SELECT id, invoice_no, customer_name, total_cents, issued_on
         FROM invoice
         WHERE shop_id = $1 AND customer_name ILIKE $2
         ORDER BY ${orderBy}
         LIMIT 50`,
  values: [shopId, `%${term}%`],   // data travels separately
});

// $queryRaw is a tagged template: each ${...} becomes a bound parameter
const rows = await prisma.$queryRaw`
  SELECT id, invoice_no, total_cents FROM invoice
  WHERE shop_id = ${shopId} AND customer_name ILIKE ${'%' + term + '%'}`;

// $queryRawUnsafe(someString) does NOT do this. Treat it like pool.query(sql).

const rows = await dataSource
  .getRepository(Invoice)
  .createQueryBuilder('invoice')
  .where('invoice.shopId = :shopId', { shopId })             // named parameter
  .andWhere('invoice.customerName ILIKE :term', { term: `%${term}%` })
  .orderBy(sortColumn, sortDir)   // both from an allow-list, never from the request
  .getMany();

Notice what the placeholders can't do. A placeholder carries a value. It can't stand for a column name, a table name or a keyword such as DESC. That is why the sort is the part most often left string-built. The fix is an allow-list: the request says total, your code looks it up in a map it owns, and only text from your map reaches the query. An unknown value falls back to a default. Use a Map or Object.hasOwn for the lookup; a plain object lookup also finds built-in keys such as toString.

ORMs and query builders help because their normal methods parameterise for you. Each one also has an escape hatch that takes a raw string: Prisma's $queryRawUnsafe, TypeORM's query() with a built string, or a .where() condition assembled with template literals. In a review, search for those first. The same goes for database functions: dynamic SQL in PL/pgSQL should use EXECUTE … USING for values and format() with %I for identifiers. Calling a stored procedure does not make string-built SQL inside it safe.

Two smaller notes. The term's own % and _ still act as wildcards inside ILIKE. That is a correctness question, not injection; escape them if exact matching matters. You met the same habit from the data side in SQL you'll actually use.

Finally, assume one query somewhere will still be wrong, and limit the damage. This is least privilege. The Partner API should log in as its own database role that can read invoices and write orders, with no rights to drop tables, read staff data or touch other schemas. If an injection slips through, the attacker gets that role's rights, not the database owner's. Row-level security from Broken access control adds one more wall between shops.

Cross-site scripting: where React protects you, and where it doesn't

XSS is injection into HTML. A user's text reaches the browser as markup, and the browser runs any script in it with your site's permissions. That script can act as the logged-in user: read what they see, submit forms, change settings.

There are two common shapes. In stored XSS, the text is saved first, such as a shop note or a product review, and runs for every person who later views it. In reflected XSS, the text comes from the request itself, often a search term in a link, and is echoed back on the page. Stored XSS is usually worse, because the victim does nothing unusual. A staff member opens a shop's profile in the back office and the script runs in a session with staff rights. A third shape, DOM-based XSS, happens entirely in front-end code that copies a value from the address bar into the page.

React helps a lot by default. When you write {shop.note} inside JSX, React puts it into the page as a text node, so angle brackets show up as characters and never become tags. That covers most of a typical app. Reviews should focus on the places where React can't help:

• dangerouslySetInnerHTML, which inserts a string as raw HTML. The name is a warning. Every use needs a reason and a sanitiser.
• URLs in href and src. React escapes the text of the attribute, but a link whose value starts with the javascript: scheme runs code when clicked. Recent React versions warn about or block such URLs; don't rely on that. Parse the URL and allow only the schemes you expect, usually https: and mailto:.
• Direct DOM access through a ref, such as setting innerHTML, and HTML built outside React: emails, PDF templates and server-rendered error pages.

Where you produce output yourself, encode for the context the value lands in. Between HTML tags, escape &, <, >, and the two quote characters. Inside an attribute, also put the attribute in quotes. Inside a URL, use encodeURIComponent for one part and a scheme allow-list for a whole link. Inside a script block or a style, avoid placing user data at all; put it in a data attribute or a JSON response instead. This is output encoding, and it belongs at the point of output, because only there do you know the context.

Rich text is the hard case. When the back office lets buyers format product descriptions with bold text, lists and links, you need to keep some HTML. Don't write your own filter with regular expressions; browsers parse HTML in more ways than any home-made filter expects. Use a maintained sanitiser such as DOMPurify, with an allow-list of tags and attributes, and run it right before rendering. Sanitising on save as well is fine, but the render-time pass is the one that protects you from old data and other writers.

Add a second layer for the bug you haven't found yet. A Content Security Policy header can tell the browser to run only scripts from your own origin, or only inline scripts that carry a per-response random value called a nonce. An injected inline script then fails to run, and the browser can send you a report. CSP limits the damage; it does not fix the encoding bug. Start in report-only mode, clean up your own inline scripts, then enforce.

Command injection: avoid the shell

The third interpreter is the operating system shell. Node's exec runs its whole argument through a shell, so the shell's special characters in a file name or an ID are read as shell syntax:

// Before: the uploaded file's original name goes through a shell
exec(`convert ${upload.originalName} -resize 200x200 thumb.jpg`);

The best fix is to need no external program at all. A library such as sharp resizes images inside your process, with no command line to inject into. When you do need a program, use execFile or spawn with an array of arguments and no shell: true. Each array item reaches the program as exactly one argument, whatever characters it contains. Use a file name your server generated, such as a random UUID, instead of the user's. A value starting with a dash can still be read as an option by the program itself, so for programs that support it, put -- before user-influenced arguments. Run the job with a short timeout and as a user that can touch only its working folder.

Validation, detection and tests

Input validation is useful and it is your second layer. Check the shape of every request at the edge: types, lengths, formats and fixed choices. In NestJS that is a DTO with class-validator decorators, as in APIs done right; elsewhere a zod schema does the same job. Validation turns the sort parameter into one of three known words before your service sees it, caps a search term at 80 characters, and rejects fields the endpoint doesn't expect.

Validation can't be the main fix, though. "O'Brien" is a valid name. A shop note must be allowed to contain quotes and angle brackets, because people type them. A block-list of "bad characters" breaks real users and still misses the next context. The separate channel fixes the cause; validation narrows what can reach it.

Then make sure you would notice an attempt or a regression:

• Errors in logs. Postgres syntax errors (SQLSTATE 42601) from an API's role are either a bug or someone probing. Log the role and the error code, and alert on a burst from one account or address.
• WAF signals. A WAF flags requests that look like injection attempts. Treat those flags as a signal of interest in an endpoint, not as protection; a WAF rule can be worked around and does nothing for the flaw.
• CSP reports. A report of a blocked inline script on a page that has none of your own is an XSS bug to hunt down.
• Tests. Unit tests that search for O'Brien, assert that the term never appears in the SQL text, and check that an unknown sort falls back. Static analysis rules that flag string-built queries and exec calls catch the pattern in new code; you will wire those into CI in Security in the pipeline and in AI features.