Page hijacking is the unauthorized takeover of a web page so its content, links, or user interactions are altered for malicious gain. In security analysis, it typically involves compromising a site or session to redirect traffic, steal credentials, inject code, or impersonate a trusted page within a broader identity or web attack chain.
What Page Hijacking Means in Practice
Page hijacking is a web attack pattern in which an adversary takes over a legitimate page or its delivery path and then changes what users see or do. The goal is usually to borrow the page’s trust, not just to deface it.
That makes the attack especially effective in environments where users already trust the domain, branding, login flow, or embedded functionality. A hijacked page can silently redirect traffic, alter links, inject malicious scripts, or imitate a normal interaction while steering the user toward credential theft or other abuse.
How Page Hijacking Changes the Security Model
Once a page is hijacked, the original security assumptions around authenticity and integrity break down. The page may still load from a familiar URL, but its content and behavior no longer reflect the owner’s intent.
This is why page hijacking is more than cosmetic defacement. It can turn a legitimate web property into an active attack surface for phishing, malware delivery, session abuse, or fraud. In some cases, the compromise also lets attackers use the page as a trusted intermediate step in a wider identity or access chain.
Common Hijack Paths and Abuse Patterns
Page hijacking can happen through direct site compromise, stolen credentials, injected code, compromised third-party scripts, or abuse of a trusted publishing account. The attacker’s access path matters less than the result, which is usually control over what the user’s browser receives or executes.
Common abuse patterns include redirecting visitors to lookalike destinations, replacing legitimate forms with credential harvesters, inserting invisible overlays that change clicks, or loading hostile JavaScript that manipulates sessions and browser state. MITRE ATT&CK Enterprise Matrix is useful for mapping the broader access and persistence techniques that often surround this kind of compromise.
Detection, Response, and Recovery
Organizations usually detect page hijacking through unexpected content changes, unusual outbound redirects, altered scripts, suspicious admin activity, or user reports that the page no longer behaves normally. Monitoring should focus on both the visible page and the delivery chain behind it.
Recovery is not just a rollback exercise. Teams need to restore the page, identify how the change was introduced, remove attacker persistence, and review whether credentials, sessions, signing keys, API tokens, or publishing accounts were exposed during the compromise. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of response through controls for access, auditability, integrity, and configuration management.
Risk and Threat Considerations
Page hijacking is dangerous because it weaponizes trust. Users often have no visual clue that a familiar page has been modified, so the attacker can capture credentials, redirect transactions, or run malicious code under the cover of a legitimate site.
Failure mechanism: The page owner or hosting environment is compromised, or a trusted dependency is altered, allowing the attacker to change page content, form behavior, or redirection logic without obvious warning signs.
Impact: Users may disclose credentials, approve fraudulent actions, execute hostile scripts, or continue interacting with a page that now serves the attacker’s goals instead of the organization’s.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1185 — Browser Session Hijacking | Page hijacking commonly overlaps with browser-session and content manipulation techniques. |
| Recommendation — Map page tampering to ATT&CK techniques and hunt for related credential theft and redirect activity. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Logging is central to spotting unauthorized page changes and suspicious admin activity. |
| CM-2 — Baseline Configuration | Baseline integrity helps identify unauthorized modifications to page assets and dependencies. | |
| Recommendation — Log content changes, admin actions, and redirect events so tampering can be detected and investigated. Baseline page assets and configuration so unauthorized changes are quickly identified and rolled back. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Page hijacking is often enabled by insecure page logic, unsafe scripts, or weak trust boundaries. |
| Recommendation — Design page delivery and client-side logic to reduce trust abuse and unauthorized modification paths. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Hijacked pages often abuse backend functions or actions exposed through weak authorization. |
| Recommendation — Enforce function-level authorization so a hijacked page cannot invoke privileged backend actions. | ||
Practitioner Guidance
Why practitioners should care: Page hijacking is often a business-impacting integrity failure, not just a web-content issue. Even a short-lived compromise can damage trust, support phishing, and undermine the reliability of user journeys that depend on the page.
What to watch for: Treat unexpected redirects, unfamiliar scripts, altered embedded content, and changes to page behavior as potential compromise signals. OWASP API Security Top 10 is also relevant when the hijacked page depends on backend calls that can be abused through weak authorization or unsafe consumption patterns.