Skip to content
Kodesec × Integrated-Systems.ai
KODESEC
Book a call

A05 · OWASP Top 10 · 4 min

Injection. When your site mistakes what a visitor types for instructions.

SQL injection, cross-site scripting (XSS) and their relatives. Different names, one mistake: text from outside gets treated as a command.

I run a

In 10 seconds

Text a visitor types, treated as a command.

What it is

Your site has search boxes, forms and web addresses where visitors type text. Injection is when that text slips through as an instruction, and your system obeys it.

Why you care

It's one of the oldest and best-known attacks, and still common. It can reach your names, addresses, phone numbers and purchase history, change what your visitors see, or run commands on your server.

What to do

Ask how your site treats what visitors type, and whether anyone independent has tested it. OWASP groups SQL injection and XSS together under this one heading in its Top 10.

For your business

What's at stake for you.

I run a

Who is affected

Your customers, and anyone who trusts you with their details.

What could leak

Names, addresses, phone numbers and purchase history.

Ask this first

“Is everything visitors type treated as plain data and never run as a command? Has that been tested?”

Meet the family

Four famous cousins, one root mistake.

Targets your database

SQL injection

Typed text becomes a database command. It can read, change or delete records. Famous for: TalkTalk, Heartland.

Targets your visitors

Cross-site scripting (XSS)

A hidden script in a page runs for everyone who views it, as if it came from you. Famous for: the MySpace Samy worm.

Targets your server

Command and code injection

Typed text becomes an instruction to the server itself. Famous for: Log4Shell.

Targets your AI assistant

Prompt injection

Text tells your chatbot to ignore its rules. The newest relative, growing as businesses add AI helpers.

Where it hides

Pick a place on your website.

Anywhere a visitor can type, post or upload is a place the site must keep text and commands apart.

yourbusiness.com/search?q=...
What's here
A search box or filter that looks things up in your database.
What goes wrong
The typed words are glued into a database command. Crafted text can add a second instruction, so the database reads, changes or deletes records it shouldn't.
Ask your team
Does our search treat what people type as plain text only? Has it been tested with deliberately hostile input?
Developers call it
SQL injection, reflected XSS

What it costs

One unguarded box, many ways to lose.

Data theft

A whole database can be read through one search box or login form.

Your pages, their words

XSS lets attackers show fake login boxes or redirect customers, on your own pages.

Control of servers

Command injection can hand over the machine your website runs on.

Fines and fallout

Because it's so well known, regulators have treated it as avoidable. Duties vary by country and sector.

For an online shop: one unguarded search box or form could expose names, addresses, phone numbers and purchase history.

Does this apply to you?

Tick what's true. Get your questions.

First

So the questions fit you

What kind of business do you run?

Real cases

Old, famous, and still happening.

SQL injection, 2015

Forgotten pages, a well-known flaw.

What it cost
In 2016 the ICO fined TalkTalk £400,000, saying its failure to apply basic security measures let the attackers in with ease.
The lesson
Injection is old and well known, so regulators treat it as avoidable. It often lives in pages nobody remembers owning.
Read the full story and sources

In October 2015 attackers used SQL injection against old web pages on TalkTalk's site, left over from a company it had acquired. The pages ran database software with a flaw whose fix had been available for years. The UK ICO found personal details of about 157,000 customers were accessed, including bank account numbers and sort codes for around 15,600.

In 2016 the ICO fined TalkTalk £400,000, saying its failure to apply basic security measures let the attackers in with ease.

Source: UK Information Commissioner's Office (October 2016).

Your part

Three decisions that are yours.

  1. 01Make it a standardRequire that everything visitors type is treated as data, never as a command, on every form and every app. It's a rule, not a one-off fix.
  2. 02Test with outsidersHave independent testers try to inject into your forms and web addresses, before launch and after major changes.
  3. 03Limit the damageDecide what each system and each chatbot is allowed to reach, so one slip can't expose everything.
For your developer: the technical layer
  • Use parameterised queries or prepared statements, and use ORMs correctly. Never build queries by joining strings.
  • Encode output for its context (HTML, attribute, JavaScript, URL) and keep framework auto-escaping on. Add a Content Security Policy to limit XSS damage.
  • Validate input against an allow-list of type, length and format as a second layer, never the only one.
  • Avoid shell commands built from user input. Use library APIs that take arguments separately.
  • Give the web app a least-privilege database account, not an admin one.
  • For LLM features: treat model output as untrusted, limit tools and data per user, and require approval for sensitive actions.
  • Combine automated scanning in CI with manual testing. A web application firewall is a safety net, not a fix.

Remember

Three things to keep.

  • Every place a visitor can type is a place text can be mistaken for a command.
  • It's old and well known, so it's seen as avoidable. Test for it, including on forgotten pages.
  • Limit what each system can reach, so a slip stays small.

What OWASP says

The essentials, slide by slide.

A05 · owasp top 10 · 01/04

OWASP Top 10 · A05

injection

Source: OWASP Top 10:2025 (CC BY 3.0) ↗

OWASP is a non-profit that publishes the industry's standard list of web risks. Safety measures adapted from the OWASP Top 10:2025 (CC BY 3.0). The people and businesses in the examples are made up.