Home / Knowledge hub / HTML injection
Knowledge hub
HTML injection
Getting your page to render markup an outsider supplied, even without running scripts.
What it means
HTML injection happens when an application puts user-supplied text into a page without encoding it, so the browser reads it as markup. A name field containing <h1> becomes a heading. A comment with an image tag loads an image from anywhere.
It is closely related to cross-site scripting. The difference is the outcome: HTML injection changes what the page shows, and XSS runs code. A strong script defence can leave HTML injection still open.
Why it matters
Even without scripts, injected markup can do harm. A fake sign-in form inside a trusted page. A link or button that sends payments to the wrong place. Content that changes the meaning of an email or invoice. Visitors trust the page because it is yours.
It can also leak data without scripts at all, through dangling markup, where an unclosed tag swallows the page's secrets into a request to the attacker. And the bug is often one small step from full XSS.
How it shows up
You meet it in comment boxes, profile fields, support tickets, email templates, PDF generators, error messages and rich text editors. Anywhere text is stored and shown back, or reflected from a URL, can break the rule that data is not markup.
The mistakes repeat. Output built with string concatenation. Encoding in one place but not in an email or export. Allowing "some HTML" with a home-made filter. Fix by encoding for the right context, using a tested sanitiser where HTML is wanted, and backing it with a content security policy.
Questions people ask
HTML injection, answered
Is HTML injection the same as XSS?
Not quite. XSS runs script in the victim's browser. HTML injection only changes the markup, though it is often a stepping stone to XSS.
Report and fix both.
Can HTML injection steal data?
Yes, without scripts. Dangling markup can send part of the page, such as a token, to an attacker's server in a request.
A strict content security policy limits this.
How do we prevent it?
Encode output for the context it appears in, HTML body, attribute or URL. Where users may supply HTML, sanitise with a maintained library and an allowlist.
Do not write your own filter.
Does input validation fix it?
Helps, but is not enough. The reliable control is encoding on output. Input checks cannot know every place the text will later appear.
Use validation as a second layer.
Where does it hide in email and PDFs?
Templates that insert names, notes or addresses into HTML emails or documents. These often miss the encoding the web pages have.
A pentest should include those outputs, not only the website.
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Dangling markup
Injected HTML that never closes, swallowing the page after it and sending it out.
Stored XSS
Malicious script saved by your app and then served to other people who view it.
Input validation
Checking that what arrives is the shape and range you expected.
Content Security Policy
A header telling the browser which scripts a page may load.
What else can your page show?
Fields that echo markup back into pages, emails and exports are tested on the running app, and in white-box mode a finding points to the file and line. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.