Front-end hijacks: when the real website turns against you

Most phishing advice comes down to one rule: check you're on the real site. Type the address yourself, use bookmarks, ignore links in messages. It's good advice — and it has a blind spot. Sometimes the real site, at the real address, starts serving something malicious.

That's a front-end hijack. The smart contracts behind a dApp can be perfectly safe while the website you use to reach them has been quietly replaced, and every transaction it asks you to sign is designed to empty your wallet.

The website is a separate thing from the protocol

A decentralised app has two halves:

• The contracts on the blockchain, which hold funds and enforce the rules.
• The front end — the website — which reads data, builds transactions and sends them to your wallet to sign.

The contracts are usually audited, public and hard to change. The front end is an ordinary website, hosted on ordinary infrastructure, and it decides exactly what lands in front of you for signing. If an attacker controls the website, they don't need to touch the contracts at all. They just need you to sign their transaction instead of the real one.

How front ends get hijacked

• DNS hijacking. The attacker takes over the domain's settings — often through the domain registrar or the account that manages it — and points the real address at their own server. The URL in your browser is correct; the site isn't.
• Compromised hosting or deployment. An attacker with access to the project's hosting, build pipeline or deployment keys pushes a modified version of the site.
• Malicious dependencies. A third-party script or library the site loads — analytics, a UI component, a wallet-connection package — is compromised, and every site using it starts serving the attacker's code.
• Injected scripts. A vulnerability lets an attacker insert code into an otherwise legitimate page.

In each case, everything about the visit looks normal. Same URL, same design, same flow — until the transaction request.

What the attack looks like

A hijacked front end usually goes for one of a few high-value requests:

• Unlimited token approvals to an attacker's address, dressed up as a normal "approve to continue" step.
• "Approval for all" on NFTs, presented as listing or claiming.
• Off-chain signatures — permits or marketplace orders — that can be submitted later to move funds without another prompt.
• Direct transfers disguised as deposits, claims or migrations.

The tell is a mismatch between what you're doing and what you're asked to sign. Swapping a small amount shouldn't require approving an unlimited allowance to an address you don't recognise. Claiming a reward shouldn't require a transfer of everything.

How to defend yourself

You can't detect a hijacked server by looking at the page. Your defence is the signing step, because that's where the attacker's intent has to become visible.

• Read every request in your wallet, not on the website. The page can say anything; the wallet shows what you're actually signing.
• Check the spender and the amount on approvals. Unknown addresses and unlimited allowances deserve a hard stop.
• Be suspicious of sudden changes in flow. A site that never asked for a signature or approval at a certain step and suddenly does is a warning.
• Use simulation where you have it. Previewing what a transaction will do catches requests whose real effect differs from the label.
• Watch announcements. Projects that detect a front-end compromise usually warn on their official channels quickly. If something feels off, check before signing.
• Revoke afterwards if you're unsure. If you approved something during a period when a site was compromised, revoke the approval right away.

This sits alongside the classic advice on phishing rather than replacing it. Checking the address protects you from fake sites; reading the request protects you from real sites gone bad.

Where SSP helps

When a dApp connected through WalletConnect asks SSP to sign, the request shows which site is asking, the network and the address, and SSP decodes common calls before you approve: transfers, approvals and NFT approval-for-all requests are labelled, with explicit warnings on the riskier ones. Messages are shown as readable text where possible, with raw data available to inspect.

Every request then needs a second approval on SSP Key, on a separate device. That doesn't stop a hijacked website from asking for something malicious — but it gives you two clear chances to see the request for what it is, neither of them on the page the attacker controls.

For teams, SSP Enterprise vaults add transaction simulation and risk warnings before signers approve, so a proposal built through a compromised front end gets a second, independent look from everyone who has to sign it.

The honest summary

A front-end hijack turns a trusted website into the attacker's tool without touching the contracts or the URL. You can't spot it by checking the address bar.

What you can do is treat every signing request as the real interface: read it in your wallet, check the spender, the amount and the recipient, and refuse anything that doesn't match what you set out to do.