Content Spoofing

An attacker manipulates content on a legitimate page - through an unvalidated parameter that gets reflected into visible page text, an unescaped redirect target shown to the user, or a similar injection point - to display misleading content under the target's real, trusted domain, without necessarily executing any script (the key difference from XSS, where the injected content runs as code rather than just displaying as text).

Confirming genuine content spoofing requires assessing how convincingly an injected value can impersonate legitimate content within that specific page's actual layout and context - a judgment call about visual/contextual deception, not a pure technical signature the way script execution is.

Manual testing that injects benign marker text into reflected parameters and evaluates how it renders within the page's actual visual context.

Tip: This is found by intercepting requests with a proxy and directly modifying any value the client is relied on to protect — the finding is confirmed the moment the server accepts a value it should have independently rejected.

Real-World Impact

Client-side enforcement of server-side security, tampering with data the client assumes is immutable, and UI elements that misrepresent what's actually happening all share the same root mistake: trusting the client to enforce something only the server can actually guarantee. A price, permission flag, or workflow state that's only checked or displayed client-side can be altered by anyone with browser developer tools or an intercepting proxy, regardless of how the UI presents it.

Content spoofing and UI misrepresentation compound this from the other direction — instead of an attacker bypassing a client-side check, a victim is shown misleading UI (a fake status, an altered display value, spoofed content) that leads them to trust something they shouldn't, which is a phishing-adjacent risk when it's exploited against other users rather than by them.

The underlying lesson across this whole family is the same one security engineering has repeated for decades: the client is not a trusted execution environment, and any security decision enforced only there should be assumed bypassed by a motivated attacker.

Prevention and Secure Design

Preventing Content Spoofing takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Re-enforce every client-side check server-side. Anything the client validates, restricts, or displays for security purposes needs an equivalent, independent check on the server — the client-side version is a UX convenience, not a control.

Never trust client-supplied state for anything security-relevant. A price, permission flag, or workflow status the client sends back should be re-derived or re-validated server-side, not accepted as sent.

Sign or server-store anything that must stay immutable. Where a value genuinely needs to travel through the client unmodified, sign it (and verify the signature server-side) rather than hoping it isn't tampered with.

Design UI to reflect actual server state, not assumed state. A UI element showing a status or value should be sourced from a live, authoritative check, not a value the client is trusted to maintain correctly on its own.

Test with a proxy that can modify requests freely. Intercept and directly tamper with every client-side-enforced value to confirm the server independently rejects the invalid version.