Form action hijacking is a web attack that silently changes where a form sends submitted data. An attacker alters the form’s action target so credentials, payments, or other sensitive input are posted to an unauthorized endpoint, often through injected code, compromised scripts, or manipulated HTML in the browser.
How form action hijacking works
Form action hijacking changes the destination of an existing form without changing the user experience. The visible page, fields, and submission button can look normal, but the browser posts the data to a different endpoint than the one the site owner intended.
That makes the attack especially effective against login forms, payment forms, account update flows, and any submission that carries sensitive input. Because the compromise happens at the delivery layer of the page, the user often has no obvious sign that the destination has been altered.
Why it is dangerous
The core danger is that the attacker receives data that users believed they were sending to a trusted application. Credentials, card data, personal information, and form tokens can all be redirected if the action target is modified at the right point in the client-side flow.
This is a web integrity failure rather than a password problem or a payment problem alone. If the page can be manipulated through injected script, compromised third-party content, or tampered HTML, then the trust relationship between the browser and the form owner breaks down before server-side controls ever see the submission.
Common attack paths and failure conditions
Form action hijacking usually appears after some other web weakness has already created a foothold. Typical paths include cross-site scripting, compromised analytics or tag-manager code, malicious browser extensions, supply-chain compromise in front-end dependencies, or HTML injection that lets the attacker rewrite the form action before submit.
The failure condition is often a weak assumption that visible page content equals trusted page behavior. If scripts can be modified, if inline content is not constrained, or if form destinations are not validated server-side, the page may silently send data off-site even though the interface appears intact.
For a broader weakness taxonomy around root causes in web content handling and unsafe page behavior, the CWE Top 25 Guide is useful context for understanding how insecure input handling and client-side manipulation create exploitable conditions.
Detection, review, and hardening
Organisations should confirm where critical forms really submit, not just what the rendered HTML initially shows. Asset inventory for front-end code, review of third-party scripts, content security policy enforcement, and integrity checks on the page lifecycle all help reduce the chance of silent destination changes.
After any suspected compromise, review whether submitted data may have left the intended trust boundary. That includes checking browser-delivered scripts, recent content changes, form templates, tag managers, and endpoint logs for unexpected submission destinations or unusual referrer patterns. For API and submission-channel abuse patterns that overlap with this risk, the OWASP API Security Top 10 and NIST Cybersecurity Framework 2.0 provide adjacent control language for access control, monitoring, and recovery.
Risk and Threat Considerations
Form action hijacking is dangerous because it turns a trusted business form into a data exfiltration path. The user still sees the expected interface, which means the attacker can quietly capture secrets, payment data, or other high-value submissions without needing to break the application’s back-end logic.
Failure mechanism: The attacker alters the form action through injected code, compromised page resources, or tampered markup, so the browser posts to an unauthorized endpoint while the page still appears legitimate.
Impact: Sensitive submissions can be stolen, replayed, or combined with other exposed data, and the compromise may persist until the page source, scripts, or dependent content are restored and reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Form submission targets are a web-service trust boundary that must resist tampering. |
| V16 — Security Logging and Error Handling | Unexpected form destinations and submission anomalies should be logged for investigation. | |
| Recommendation — Validate form submission targets and server-side request handling against unauthorized destination changes. Log suspicious submission-path changes and investigate unexpected form routing promptly. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Client-side form hijacking exploits weak validation of supplied or transformed input paths. |
| SC-18 — Mobile Code | Injected or third-party script code can alter form behavior and redirect submissions. | |
| Recommendation — Enforce validation on form inputs and submission handling before data is accepted or forwarded. Restrict and monitor active content that can modify browser-side form behavior. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure web application controls address tampering with form logic and page resources. |
| Recommendation — Harden web applications so untrusted code cannot rewrite submission destinations. | ||
Practitioner Guidance
What to watch for: Treat any high-value form as a trust boundary, not a static UI element. The destination, supporting scripts, and embedded third-party components should be reviewed together, because the action target can be changed without changing what the user sees.
Governance implication: Ownership of the form should include page integrity, dependency review, and monitoring of the full submission path. Security teams should be able to answer which code is allowed to alter form behaviour and how unexpected destination changes would be detected.