DEV Community

ohmygod
ohmygod

Posted on

Frontend Is the New Attack Surface: What BonkFun's Domain Hijack Teaches Us About dApp Security Beyond Smart Contracts

#security #solana #defi #web3

The crypto industry spends millions on smart contract audits. Attackers just hijack the website instead.

On March 12, 2026, hackers compromised the domain of BonkFun, a Solana memecoin launchpad. They didn't find a reentrancy bug. They didn't exploit a flash loan. They injected a wallet-draining script disguised as a Terms of Service prompt. Users who "accepted" the fake TOS had their wallets emptied within seconds.

~35 wallets were drained. ~$23,000 lost. A relatively small incident by crypto standards — but it's a symptom of a much larger problem that has already cost the industry billions.

The Pattern Nobody's Fixing

BonkFun wasn't the first. It won't be the last. Here's the historical ledger:

  • Badger DAO (Dec 2021): Cloudflare API key compromise → malicious approval scripts → $120M lost
  • Curve Finance (Aug 2022): DNS server breach → transaction rerouting → $570K lost
  • Squarespace DeFi wave (Jul 2024): DNS hijack across multiple protocols
  • npm supply chain attack (Sep 2025): Compromised chalk/debug packages → address replacement
  • Bybit / Safe frontend (2025): Compromised JS dependency → modified multisig transactions → $1.5B lost
  • Curve Finance again (May 2025): DNS hijack → fake approval site → $3.5M lost
  • BonkFun (Mar 2026): Domain hijack → fake TOS wallet drainer → $23K lost

Notice the trend: the attacks are getting simpler while the targets get bigger. You don't need a Solidity PhD to hijack a domain registrar account or phish an npm maintainer.

Anatomy of a Frontend Attack

Every frontend attack follows a three-stage kill chain:

Stage 1: Compromise the Delivery Layer

The attacker doesn't need access to the smart contract. They need access to what delivers the smart contract interaction to users:

  • Domain registrar accounts (weak passwords, no 2FA)
  • CDN/hosting provider APIs (leaked Cloudflare keys)
  • npm/package dependencies (phished maintainer accounts)
  • DNS records (registrar-level hijacking)

Stage 2: Inject Malicious Transaction Logic

Once inside, the attacker modifies what users see and sign:

// The legitimate transaction
const tx = {
  to: PROTOCOL_VAULT,
  data: encodeDeposit(amount)
};

// What the attacker's injected script actually submits
const tx = {
  to: ATTACKER_WALLET,
  data: encodeTransferAll()  // or unlimited approval
};
Enter fullscreen mode Exit fullscreen mode

The user's wallet shows a transaction to sign. The wallet simulation might catch it — if the user reads it. Most don't.

Stage 3: Harvest with Speed

Frontend attacks have a short window. The attacker drains as many wallets as possible before:

  1. The team notices
  2. Community spreads warnings
  3. The domain/frontend is recovered

BonkFun's attacker got ~35 wallets in the window. Badger DAO's attacker got 500+. The Bybit attacker only needed one — but it was a multisig controlling $1.5B.

Why Smart Contract Audits Don't Help

Here's the uncomfortable truth: every single one of these protocols could have had a perfect audit score.

Smart contract audits verify on-chain logic. Frontend attacks operate entirely off-chain until the moment a user signs a transaction. The audited contract works exactly as designed — it's just that the user was tricked into signing something they didn't intend.

This is the Web3 equivalent of a phishing attack, but with a crucial difference: the phishing page IS the official website.

The Defense Playbook

For Protocol Teams

1. Treat Frontend Infrastructure as Critical as Smart Contracts

Your domain registrar account, CDN API keys, and npm publish tokens are as sensitive as your contract deployer keys. Apply the same security posture:

  • Hardware-key 2FA on all infrastructure accounts
  • Separate credentials for deployment vs. development
  • Principle of least privilege for all API tokens
  • Regular audit of who has access to what

2. Implement Subresource Integrity (SRI)

Lock down external scripts with integrity hashes:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
        crossorigin="anonymous"></script>
Enter fullscreen mode Exit fullscreen mode

If an attacker modifies the script, the browser refuses to execute it.

3. Deploy Content Security Policy (CSP) Headers

Restrict what scripts can run on your domain:

Content-Security-Policy: 
  script-src 'self' 'sha256-{hash}';
  connect-src 'self' https://api.mainnet-beta.solana.com;
Enter fullscreen mode Exit fullscreen mode

This prevents injected scripts from executing or connecting to attacker-controlled servers.

4. Consider IPFS/On-Chain Frontend Hosting

Protocols like Uniswap maintain IPFS-hosted frontends that are content-addressed — changing the content changes the hash, making silent tampering detectable. ENS domains can point to IPFS hashes, removing the DNS single point of failure.

5. Pin Dependencies and Audit the Supply Chain

// package-lock.json with exact versions
"dependencies": {
  "ethers": "6.13.4"  // exact, not ^6.13.4
}
Enter fullscreen mode Exit fullscreen mode

Use npm audit, Snyk, or Socket.dev to monitor for compromised packages. Consider vendoring critical dependencies.

6. Transaction Simulation and Warning Systems

Integrate with services like Blowfish, Blockaid, or Wallet Guard that simulate transactions and flag suspicious patterns before users sign.

For Users

1. The Burner Wallet Rule

Never connect your main wallet to a dApp directly. Use a dedicated "hot" wallet with limited funds. Transfer assets to cold storage after each session.

2. Read Before You Sign

Your wallet shows you what you're approving. Read it. If a "Terms of Service" prompt asks you to sign a blockchain transaction — that's a red flag. TOS acceptance doesn't require on-chain signatures.

3. Bookmark, Don't Search

DNS hijacks work because users type URLs or click search results. Bookmark the official URLs of every protocol you use. Better yet, use ENS/SNS names with a resolver you trust.

4. Revoke Stale Approvals

Periodically audit and revoke token approvals:

An unlimited approval you forgot about from 2023 is a ticking time bomb.

5. Use Wallets with Built-in Simulation

Modern wallets like Phantom (Solana) and Rabby (EVM) include transaction simulation. If the simulation shows unexpected token transfers or approvals — reject the transaction.

The Bigger Picture

The crypto industry has a security model problem. We've built incredibly robust, formally verified, heavily audited on-chain systems — and then we serve them through the same fragile Web2 infrastructure that gets compromised every day.

The chain of trust looks like this:

User → Browser → DNS → CDN → Frontend JS → Wallet → RPC → Smart Contract
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       All of this is Web2 attack surface
Enter fullscreen mode Exit fullscreen mode

Every link before the wallet is a potential injection point. And unlike smart contract exploits, frontend attacks don't leave audit trails on-chain until it's too late — the malicious transaction looks identical to a legitimate one.

The BonkFun incident cost $23K. The Bybit/Safe frontend compromise cost $1.5B. The next one could be worse. The attack surface isn't shrinking — it's growing with every new npm dependency, every new CDN endpoint, every new team member with registrar access.

Smart contract security got serious after The DAO hack in 2016. Frontend security hasn't had its DAO moment yet. But with $1.5B already lost to a single supply chain attack, we're running out of excuses.

This article is part of an ongoing series on Web3 security research. Follow for deep dives into vulnerability analysis, audit tooling, and security best practices across Solana and EVM ecosystems.

Top comments (0)