Approval Phishing

Overview

Approval Phishing is a wallet-targeted attack that tricks a user into signing a token allowance, operator approval, permit, or similar authorization that enables later asset transfer by an attacker. The control exists to reduce technical, fraud, and financial risk arising from blockchain transactions, signatures, smart contracts, clients, bridges, wallets, and public transaction data. It differs from direct transaction theft because the signature may grant reusable authority without immediately moving assets. It should be interpreted alongside Phishing because the concepts can affect the same decision without representing the same control, event, or risk.

The workflow identifies the exact network, contract, implementation, message, signer, asset, dependency, and expected state transition. Systems should verify domain and chain context, authoritative addresses, signatures, nonces, code or client versions, confirmations, and the difference between observable data and inferred ownership. In this context, defenses should decode requested permissions, identify spender and scope, warn on unlimited or unusual approvals, verify domains and contracts, support revocation, simulate consequences, and separate routine login signatures from asset authority.

It should connect the term to EIP-712 Typed Data where that relationship changes access, transaction treatment, investigation, communication, or recovery.

Records should retain transaction and block identifiers, contract addresses, network and chain ID, decoded input, signer, signature domain, client version, timestamps, confirmations, attribution source, alerts, decisions, and resulting state. Reorganizations, bridges, proxies, and off-chain dependencies require explicit treatment.

Useful measures include affected value, suspicious exposure, signature warnings, replay or duplicate attempts, client concentration, failed validation, contract mismatches, investigation time, unresolved attribution, and recovery outcomes.

The relationship with Counterfeit Token should be documented where it affects residual risk or control ownership.