Front-End Attack

What Is a Front-End Attack?

A front-end attack is a class of exploit where an attacker compromises the user-facing interface of a decentralized application (dApp) rather than its on-chain smart contracts. The attacker modifies the website code so that when users interact with the protocol, their transactions are silently altered: approvals are redirected to the attacker's address, transaction parameters are changed, or wallet-draining scripts are injected into the page.

This attack exploits a fundamental tension in decentralized finance: while the smart contract layer may be fully audited, immutable, and trustless, the web interface through which most users interact with those contracts runs on traditional, centralized infrastructure. DNS registrars, CDN providers, npm package repositories, and web hosting services all represent single points of failure that attackers can target. The blockchain acts as the settlement layer, but the frontend is where users make decisions about what to sign.

Front-end attacks are particularly dangerous because they are invisible to the average user. The compromised site looks identical to the legitimate one. The URL may even be correct if the DNS itself was hijacked. Users who rely solely on visual cues have no way to detect the manipulation without inspecting the raw transaction data before signing.

How It Works

Front-end attacks target the Web2 infrastructure that serves a dApp's user interface. There are several distinct attack vectors, each exploiting a different layer of the web stack.

DNS Hijacking

In a DNS hijacking attack, the attacker gains control of the domain's DNS records, typically by compromising the domain registrar account. They change the DNS records to point the domain to a server hosting a malicious clone of the legitimate site. Users who type the correct URL are silently redirected to the attacker's server, where a fake frontend prompts them to approve malicious transactions.

DNS hijacking is especially effective because the URL in the browser appears correct. Users cannot distinguish the attack from a legitimate visit unless they verify SSL certificates or inspect the raw transaction data. This vector overlaps with BGP hijacking, which can intercept traffic at the network routing level rather than the DNS layer.

CDN and Hosting Compromise

Many dApps use content delivery networks (CDNs) and cloud hosting services like Cloudflare Workers, Vercel, or AWS to serve their frontend code. If an attacker compromises API keys or credentials for these services, they can inject malicious JavaScript directly into the served pages without touching the domain's DNS at all.

This vector is harder to detect than DNS hijacking because the domain, SSL certificate, and hosting infrastructure all remain legitimate. The malicious code runs within the trusted origin, bypassing browser security policies like Content Security Policy (CSP) unless the CSP is configured with strict hash-based or nonce-based directives.

Dependency Poisoning

Modern web applications depend on hundreds of npm packages. If an attacker compromises a popular package or one of its transitive dependencies, they can inject malicious code that runs in every application that imports it. This is a form of supply chain attack targeting the software build pipeline rather than the hosting infrastructure.

In December 2024, the @solana/web3.js library (versions 1.95.6 and 1.95.7) was compromised in a supply chain attack. The malicious versions contained code that exfiltrated private keys, enabling attackers to drain wallets of any application using those versions. This demonstrated how a single compromised dependency can cascade across an entire ecosystem.

The Attack Lifecycle

Regardless of the specific vector, most front-end attacks follow a similar pattern:

1. The attacker gains access to one component of the Web2 stack: a registrar account, CDN API key, or package maintainer credential
2. Malicious code is injected into the frontend, often targeting wallet interactions: token approval calls, transaction parameters, or contract addresses
3. Users visit the compromised site and interact with what appears to be the normal interface
4. The injected code modifies transactions before they reach the user's wallet for signing, or prompts additional malicious approvals alongside legitimate ones
5. Users sign the altered transactions, granting the attacker unlimited token approvals or directly transferring funds
6. The attacker drains approved wallets, often in a single batch once enough approvals have accumulated

Notable Incidents

BadgerDAO: $120 Million (December 2021)

The BadgerDAO attack remains one of the largest front-end exploits in DeFi history. Attackers compromised a Cloudflare Workers API key that had been created without the knowledge of Badger engineers. Using this key, they periodically injected a malicious script into the BadgerDAO website that prompted users to approve unlimited token spending to the attacker's address.

The attacker operated silently for weeks, accumulating approvals from nearly 200 accounts. On December 2, 2021, they drained the approved wallets in under 10 hours, stealing approximately $120 million. A single institutional victim lost over $50 million in wrapped Bitcoin. The smart contracts were never exploited: the attack was entirely at the interface layer.

Curve Finance: DNS Hijack (August 2022)

On August 9, 2022, attackers compromised the nameserver at Curve Finance's DNS registrar (iwantmyname), redirecting traffic from curve.fi to a malicious clone. The clone prompted users to approve a contract that would drain their wallets. Approximately $575,000 was stolen before the team identified the issue and directed users to curve.exchange, an alternate UI that was unaffected.

The underlying smart contracts and liquidity pools remained completely secure throughout the incident, underscoring how front-end attacks bypass on-chain security entirely.

Curve Finance: Second DNS Attack (May 2025)

On May 12, 2025, Curve Finance suffered a second DNS hijack when attackers gained access to the registrar for the .fi domain. Users were redirected to a static decoy page that mimicked Curve's interface and attempted to prompt wallet signatures. The Curve team responded by redirecting the domain to neutral nameservers and launching curve.finance as a secure alternative. No user funds were lost in this instance, but the CRV token price dropped over 8% as traders reacted to the incident.

Squarespace Domain Hijack Wave (2024)

In 2024, a coordinated wave of DNS hijacking attacks targeted multiple DeFi protocols whose domains were registered through Squarespace. These domains had originally been registered at Google Domains and were force-transferred to Squarespace as part of an asset purchase agreement. The migration created a window of vulnerability that attackers exploited to redirect visitors to phishing sites hosting wallet drainers.

Front-End Attacks vs. Smart Contract Exploits

Front-end attacks differ fundamentally from smart contract exploits in where the vulnerability lies and how it is mitigated.

A smart contract audit does nothing to prevent front-end attacks. The contract code can be flawless, but if the interface tricks users into signing approvals to the wrong address, funds are lost all the same. This makes front-end attacks a distinct and complementary threat that requires its own set of defenses.

Mitigations

Transaction Simulation and Review

Transaction simulation tools show users the expected outcome of a transaction before they sign it. Wallet extensions and built-in wallet features can display which tokens will be transferred, which approvals will be granted, and to which addresses. If a transaction requests an unexpected approval or sends funds to an unfamiliar address, users can reject it before signing.

Hardware Wallet Confirmation

Hardware wallets display transaction details on a separate, trusted screen that the compromised website cannot control. Users can verify the recipient address, token amounts, and approval targets on the device before signing. This creates an air gap between the compromised frontend and the signing step.

Decentralized Frontend Hosting

Hosting frontend code on IPFS (InterPlanetary File System) with ENS (Ethereum Name Service) resolution eliminates the DNS registrar as a single point of failure. Content on IPFS is addressed by its cryptographic hash, so any modification to the frontend code would change its address, making tampering detectable. Multiple independent gateways can serve the same content, removing reliance on any single hosting provider.

Dependency Security

To guard against dependency poisoning, development teams can pin exact package versions, use lockfiles with integrity hashes, run automated vulnerability scanning, and limit the number of third-party dependencies. Subresource Integrity (SRI) tags on script elements ensure that browsers only execute scripts whose content matches a known hash.

<!-- Subresource Integrity prevents tampered scripts from executing -->
<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxA..."
  crossorigin="anonymous"
></script>

User-Side Precautions

• Bookmark known-good URLs rather than typing them or following links from search engines or social media
• Verify contract addresses against official documentation or on-chain records before approving transactions
• Use wallet features that flag unusual approval requests, such as unlimited token allowances
• Revoke stale token approvals regularly to limit exposure if a past approval was malicious
• Check multiple sources (official social accounts, community channels) if a dApp behaves unexpectedly

Why It Matters

Front-end attacks highlight a core challenge in the transition from Web2 to Web3: decentralizing the backend (smart contracts on a blockchain) does not automatically decentralize the frontend. Most users interact with DeFi through conventional websites served by conventional infrastructure, which means the security of user funds depends on the security of DNS registrars, CDN providers, and npm packages just as much as it depends on smart contract audits.

As the DeFi ecosystem matures, protocols are increasingly investing in frontend security: decentralized hosting, multiple independent frontends, transaction simulation as a default wallet feature, and operational security around deployment credentials. For users, understanding front-end attacks is essential to practicing safe self-custody: verifying what you sign matters as much as controlling your own keys. For a deeper look at how attackers exploit web infrastructure to target crypto users, see the research on address poisoning attack defense and wallet security attack surfaces.

Risks and Considerations

• Front-end attacks require user interaction (signing a transaction) to succeed, but social engineering and urgency tactics often pressure users into signing without careful review
• Even decentralized hosting is not a complete solution: IPFS gateways can be compromised, and ENS domains can be transferred if the owner's keys are compromised
• The proliferation of DeFi protocols means that any single compromised dependency can affect dozens of frontends simultaneously, creating systemic risk across the ecosystem
• Transaction simulation tools can be bypassed by sophisticated attacks that detect simulation environments and behave differently during preview versus actual execution
• Recovery is difficult: because blockchain transactions are irreversible, funds stolen through front-end attacks are typically laundered through mixers or bridges and cannot be recovered without law enforcement intervention

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.