CSP Form Hijacking

How CSP Form Hijacking Works

CSP form hijacking abuses a site’s own trusted form flow rather than replacing the page outright. By injecting script or manipulating form actions, the attacker can redirect submitted data to an attacker-controlled destination while the user still sees a familiar interface.

The abuse is effective because users tend to trust an intact login, checkout, or support form. If the page continues to render normally, the malicious redirection can blend into ordinary browser behaviour and escape quick visual inspection.

Why It Is Dangerous

This attack can capture high-value data in transit, including credentials, payment details, and session material. Because the submission often originates from a legitimate page and a legitimate user action, the exfiltration path may look like normal application traffic until the destination or payload is examined closely.

It is especially dangerous when a site relies on permissive inline scripting, weak form destination controls, or vulnerable third-party content. In those cases, the browser is still enforcing policy, but the policy is no longer protecting the form journey the application actually depends on.

Common Abuse Paths

Form hijacking usually rides in through script injection, malicious browser-side dependencies, compromised tags, or an application bug that lets an attacker alter form attributes such as action or submit handlers. The attacker does not need to replace the entire site, only the trust path the form uses.

Some attacks are overtly malicious, while others exploit a subtle configuration gap. For example, a page may allow unexpected destinations for form posts or load code from a dependency that can rewrite the submission target at runtime.

What Defenders Need to Watch

Defenders should look for unexpected form destinations, suspicious client-side script changes, and outbound requests that do not match the application’s normal submission patterns. Review browser-side code paths, dependency integrity, and any place where user input can influence a form action or submission handler.

Because the page may still function normally for users, detection often depends on comparing expected application behaviour with actual network egress. A strong baseline of normal form targets and browser-side behaviour makes it easier to spot subtle redirection.

Risk and Threat Considerations

CSP form hijacking can turn a trusted web flow into a silent data theft channel. The main risk is not page defacement, but invisible diversion of credentials, card data, or session-related information from a legitimate interaction.

Failure mechanism: The attacker gains code execution or form control through injected script, compromised dependencies, or weak form-action restrictions, then rewrites where the browser sends submitted data.

Impact: Sensitive user input can be exfiltrated without breaking the visible page flow, which increases the chance of credential theft, account takeover, fraud, and delayed incident discovery.

Practitioner Guidance

Why practitioners should care: Treat form submission paths as a security boundary, not just a front-end convenience. If the application depends on browser-side logic to protect where data goes, the integrity of that logic becomes part of the control set.

What to watch for: Pay attention to code paths that can alter form actions, override submit behaviour, or introduce untrusted third-party JavaScript. Those are the points where a normal-looking page can become a covert exfiltration channel.

Related resources from NHI Mgmt Group

• How can security teams reduce the risk of session hijacking in SaaS environments?
• Why does MFA not stop session hijacking?
• What is the difference between credential theft and session hijacking?
• What is the difference between session hijacking and credential theft?