Warning signs include a script loaded from an unexpected remote host, a button that suddenly becomes the trigger for wallet activity, and approval requests that appear unrelated to the user’s visible action. Another red flag is a request for an unusually large or unlimited allowance, especially when it appears only after a specific page interaction rather than a clear transaction flow.
How dApp hijacking turns normal clicks into approval fraud
A hijacked dApp page usually does not look obviously broken. The attacker’s goal is to preserve the visible user flow while swapping the hidden transaction intent, so the page still appears to behave normally even as it routes the wallet toward an approval the user never intended.
The most useful clue is mismatch, between what the page visually suggests and what the wallet is being asked to sign. If the interface says one thing but the approval prompt is for a different token, contract, spender, or amount, the page has likely been altered to exploit that trust gap.
That is why unexpected remote scripts matter. A page that suddenly pulls JavaScript from an unfamiliar host can change button handlers, inject wallet calls, or replace the transaction payload after the page loads. In practice, the hijack often appears only at the last step, when the user clicks a harmless-looking control that now triggers approval logic instead of the expected action.
Another common sign is an approval flow that appears only after a specific interaction, such as pressing a claim, connect, continue, or confirm button. Legitimate dApps usually make the purpose of an approval easy to understand before the wallet prompt appears. When the request emerges only after a click that has little visible relationship to token allowance, treat that as a strong warning that the page has been manipulated.
What the wallet prompt and allowance amount reveal
Unauthorized token approvals are often exposed in the allowance itself. A request for an unlimited or unusually large allowance is especially suspicious when the user is only performing a narrow action, such as a mint, swap, or login step. That pattern can indicate the page has redirected a routine interaction into permission to spend far more than the user expected.
Pay close attention to the spender address and the asset being approved. If the prompt does not match the contract or protocol the user is visibly engaging with, the page may be substituting a malicious contract for the legitimate one. The same is true when the approval is technically valid but contextually wrong, such as a broad ERC-20 approval presented during an unrelated page event.
For a practitioner, the key signal is not just that an approval exists, but that the approval was not clearly grounded in the user’s visible intent. If the action sequence is vague, if the allowance is excessive, or if the prompt appears after a UI event that should not require token permission, the safest assumption is that the page or one of its dependencies has been hijacked.
Risk and Threat Considerations
Hijacked approval flows create immediate asset risk because a single malicious allowance can give a hostile spender ongoing authority over a token balance. The threat is amplified by the fact that the abuse can look like normal user behaviour, so defenders may not notice until funds move or a follow-on drain occurs.
Failure mechanism: An attacker alters page logic, injected script, or button wiring so the user unknowingly approves a malicious spender or grants an excessive allowance that can be exercised later without further user action.
Impact: The wallet may remain technically uncompromised while the token balance becomes reachable by the attacker, creating persistent exposure, potential draining, and difficult-to-reverse loss of control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Input and Output Tampering | Page hijacking alters the transaction path the user sees versus what the wallet signs. |
| A3 — Tool and Action Misuse | A manipulated dApp button can invoke an unintended approval action through wallet tooling. | |
| Recommendation — Validate that the displayed action and signed approval remain aligned before allowing a wallet request. Restrict wallet-triggering actions to approved flows and verify the invoked contract before confirmation. | ||
| MITRE ATT&CK | T1189 — Drive-by Compromise | Unexpected remote scripts can compromise a page and alter its behavior at the point of interaction. |
| Recommendation — Inspect web pages that load untrusted code and monitor for injected transaction logic. | ||
Practitioner Guidance
What to verify: Treat the spender, token, and allowance size as the primary evidence, not the page’s marketing copy or button label. If the prompt is not easy to explain in one sentence from the visible user journey, investigate before approving.
Common mistake: Teams often validate only the destination site and ignore third-party scripts, wallet pop-ups, and post-click transaction changes. In approval fraud, the compromise is frequently in the interaction path, not the headline page content.
Practitioner takeaway: The decisive control is user intent correlation, approval should be accepted only when the wallet request clearly matches the visible action, the expected contract, and a bounded allowance.
