HTML Injection and Content Spoofing: Fake Text on Real Pages

Short answer: Content spoofing happens when a page displays text taken from the web address or a form without checking it, so that an attacker can make your real site show a message of their own choice. If the page also accepts HTML tags, the attacker can add links, buttons or forms. The fix is to treat all incoming text as data: escape it when you show it, and use fixed messages in place of text from the address.

What content spoofing is

Many sites show a short message after an action: “Thank you, your message was sent”, “No results found for your search”, or “Page not found”. Some of them build the message from a value in the address, for example ?message=Thank+you. If the page simply prints whatever it receives, anyone can write a link with a different message. A visitor who clicks it sees the genuine domain in the address bar, the usual design, and an attacker’s sentence in the place where the site’s own message would be.

The false text can say that an account is locked and that the visitor should call a number, that a prize is waiting or that a payment failed and must be confirmed. Because the page is real, the message looks official, and a careful person who would doubt an unknown website may trust it.

HTML injection: the stronger form

If the page prints the value as HTML, without escaping it, the attacker can insert more than words. They can add a link that goes to a fake login page, an image, a styled box that covers the real content, or even a complete form that sends the visitor’s input to another server. This is called HTML injection.

It is close to cross-site scripting, and often found in the same places. The difference is that the attacker injects markup, and not necessarily script. Browsers and filters sometimes block script but not plain HTML, so this weaker flaw may remain even where the stronger one is fixed. If script can be injected, the problem is more severe, as explained in the guide to cross-site scripting.

Where it appears

Search result pages. “You searched for …” followed by whatever was typed. See the related risks in internal search result pages.
Error pages. A 404 page that prints the missing path, or an error page that prints a message from the address. Safe pages are discussed in the guide to custom 404 pages.
Thank-you and status messages. Notices that are passed in the address after a form is sent or a login fails.
Login and registration pages. A parameter that prefills a name or shows a notice.
Redirect and return pages. Pages that show “You are leaving our site to go to …” with a chosen destination. See open redirects.
Comments, reviews and profiles. User content that allows HTML, so that one visitor can insert markup that others will see.
Email templates and notifications. Messages sent by the site that insert a name or a message from a form. See email header injection for a related problem.
Printed or exported pages. Reports and PDFs built from user input.

Why it is more than a prank

Phishing with a trusted address. The link really goes to your domain. Email filters and visitors judge it by that domain, so it passes checks that a fake domain would fail. Compare the tricks in lookalike domains.
Brand damage. Your page appears to say something offensive, false or fraudulent, and screenshots travel.
Customer harm. Visitors may call a scam number or hand over payment details after reading a message on your site.
Search results pollution. If such pages get crawled, spam text may appear in results under your name. Spammers have used site search pages for this purpose.
A step to bigger attacks. Injected markup can be used for clickjacking, fake forms or to trick people into actions on your site.

The risk to the site itself is lower than with script injection or database attacks, so some teams rank it as minor. But when the audience is a customer who trusts your name, the harm can be large.

How to test for it

Test only your own site. Look for pages that show text from the address, and try harmless input.

Find parameters that appear on the page. Try a search, trigger an error and complete a form, and look at the address after each action.
Change the value to a plain word. If the new word shows up on the page, the page repeats input.
Try a harmless tag. Use something like a bold tag around a word. If the word appears in bold, the page does not escape HTML.
Check the page source, not just the screen. Look for your input in the code and see whether special characters were turned into safe forms.
Test every place that shows user text, including emails, profile pages and exports.

If you find a flaw, treat it seriously and fix it, then test again.

How to fix it

1. Prefer fixed messages

The safest way to show a status message is not to pass the text at all. Pass a short code and let the page choose the message from a fixed list: ?status=sent shows “Thank you, your message was sent”. If the code is unknown, show nothing. An attacker can then only select among your own sentences.

2. Escape output

When you must show user text, convert special characters into harmless forms at the moment of display. In HTML, angle brackets, quotes and ampersands are escaped, so that the browser shows them as characters and does not treat them as markup. Use the escaping functions of your framework or CMS, and escape for the right context: HTML text, an attribute, a link or a script block each need their own rules. Do not write your own filter with simple replacements.

3. Validate input

Accept only what the field needs. A name does not need angle brackets, an order number is digits, and a language is a short code. Use an allowlist of permitted characters and lengths, and reject the rest. Validation is a second layer and does not replace escaping.

4. Sanitise rich content with an allowlist

If users can post formatted text, use a tested library that keeps a short list of safe tags and attributes, and removes the rest. Block forms, frames, scripts, event attributes and dangerous link types. Never rely on blocking a list of bad words.

5. Add browser protections

A Content Security Policy limits what the page can load and where forms can send data, which reduces the damage from injected markup. See the content security policy guide. It does not stop fake text, but it makes injected forms and external images harder to use.

6. Keep spoofable pages out of search

Add noindex to result and error pages that echo input, and avoid linking to them. This limits spam that targets your pages.

A plan for your team

Add a rule to your coding checklist: no text from the address or a form is printed without escaping.
Review all notice and error pages, and replace passed text with codes.
Include these pages in your security tests after each release. The website security audit checklist can serve as a base.
Keep software and plugins updated, since many injection flaws are found in third-party code. See the guide to reading security advisories.
Give visitors a way to report suspicious messages on your site.

A realistic example

A regional clinic has a booking page that shows a banner after a failed form: the banner text comes from a value in the address. An attacker notices this and sends patients an email that looks like a reminder, with a link to the real booking page. The banner now reads that the appointment has been cancelled because of an unpaid fee, and tells the patient to call a number to pay. Everything else on the page is genuine, including the logo, the padlock and the address. Several patients call, and some pay.

The clinic’s developers never wrote code to display attacker text. They only wrote code to display a message, and forgot that anyone can write the address. The repair takes an hour: the banner now reads a code, such as “failed”, and picks the sentence from a short fixed list. Any other value shows no banner. The lesson is that every value that reaches a page from outside is written by someone else, and the page must decide what it means.

How Site AI Audit helps

Site AI Audit does not send test payloads or submit forms, so it cannot find content spoofing in a particular page. It checks the public layer that makes injected content less harmful and easier to spot: security headers, exposed software versions, the SSL certificate and the redirect from HTTP to HTTPS, together with SEO findings such as noindex and error pages. The free check covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring and alerts.

The bottom line

A page that repeats what it is given lets strangers speak in your voice. Use fixed messages in place of passed text, escape everything that you display, sanitise rich content with an allowlist and test the pages that show notices. These steps are small, and they keep your domain from becoming a tool for scams.

FAQ

Is content spoofing the same as XSS?

No. Content spoofing shows false text or markup. XSS runs attacker script in the visitor’s browser. They have the same cause, unchecked output, and the same fixes.

Can a link on my domain really be dangerous?

Yes. Because the address is genuine, filters and visitors trust it. If the page shows attacker text, the link becomes a convincing scam.

Does a firewall stop it?

It may block obvious payloads, but plain sentences pass. Fix the code that prints the input, and use the firewall as an extra layer.

Should I worry about 404 pages?

Yes, if they print the requested path. Escape it or do not print it. A fixed “page not found” message is the safest.

How often should I test for it?

After any change that touches messages, forms, search or errors, and as part of your regular security review.