| name | pentest-dapps |
| description | How to pentest decentralized applications (DApps). Use this skill whenever the user mentions DApps, Web3 applications, blockchain applications, smart contracts, or wants to audit/penetrate test any decentralized application. This includes NFT platforms, DeFi protocols, cross-chain bridges, and any application that interacts with blockchain technology. Make sure to use this skill when the user asks about Web3 security, DApp vulnerabilities, or blockchain application testing. |
DApp Pentesting Guide
A comprehensive guide for security testing of decentralized applications.
Understanding DApp Architecture
Before testing, identify which architecture type you're dealing with:
API-less DApps
- Fully decentralized, no centralized backend
- Client interacts directly with blockchain via wallet
- Attack surface: primarily client-side and smart contract
- Focus: wallet interactions, transaction signing, smart contract vulnerabilities
API-Enabled DApps
- Blockchain core with centralized APIs for data
- Mostly decentralized (e.g., NFT minting apps)
- Attack surface: API endpoints + client-side + smart contracts
- Focus: API security, image upload handling, minting logic
Full-Scale DApps
- Blockchain + centralized backend + APIs
- Partially decentralized (e.g., cross-chain bridges)
- Attack surface: backend, APIs, client, smart contracts
- Backend can perform blockchain operations
- Focus: backend-blockchain sync, bridge logic, admin keys
Web2 Vulnerabilities in DApps
Traditional web vulnerabilities still apply but with amplified impact in Web3 contexts.
Client-Side Vulnerabilities (High Impact)
- XSS: Can execute JS to interact with wallet and convince users to sign malicious transactions
- Content tampering: Can modify transaction details before user signs
- Impact: Even with wallet review, attackers can trick users into signing harmful operations
Server-Side Vulnerabilities
- Present in DApps with backend servers
- Impact varies by architecture:
- Backend-only public data: reduced attack surface
- Backend with private keys: catastrophic (fund theft, account takeover)
- Test for: exposed keys, admin access, API authentication
Web3-Specific Attack Vectors
Mishandled On-Chain Transactions
- Incorrectly formatted or unrestricted transaction APIs
- Lack of response-waiting and block-confirmation logic
- Exposure of sensitive data in transactions
- Improper handling of failed, reverted, or internally-typed transactions
- Malicious calldata injections
Smart-Contract-Driven Backend Attacks
- Storing/syncing sensitive data between contracts and databases without validation
- Unchecked event emissions or contract addresses
- Exploitable contract vulnerabilities poisoning backend logic
Flawed Crypto-Asset Operations
- Misprocessing different token types (native vs. ERC-20)
- Ignoring decimal precision
- Failed transfers or internal transactions
- Accepting fake, deflationary, rebase, or slippage-prone tokens without validation
- Payload injections via token metadata
Common Vulnerability Scenarios
1. Wasted Crypto in Gas via Unrestricted API
What to test: Can you force the backend to call smart contract functions that consume gas?
How to test:
- Send requests with no limits to trigger backend contract calls
- Example: Send ETH account numbers to registration endpoints without rate limiting
Impact: Attacker forces victim to pay gas fees
2. DoS via Poor Transaction Time Handling
What to test: Does the backend keep HTTP requests open until transactions complete?
How to test:
- Send multiple concurrent requests to exhaust backend resources
- Monitor backend resource usage during slow blockchain confirmations
Impact: Denial of service
3. Backend-Blockchain Desync (Race Condition)
What to test: Does the backend give items/funds before blockchain confirmation?
How to test:
- Send withdrawal request, then immediately use those funds for purchases
- Attempt to use same coins for multiple purchases before balance updates
Impact: Free items, double-spending
4. Smart Contract Address Validation
What to test: Does the backend validate contract addresses properly?
How to test:
- Deploy fake contract with similar address
- Send funds to fake contract, trick backend into thinking it's the real contract
- Test bridge endpoints with malicious contract addresses
Impact: Token theft, bridge exploits
5. Mishandling of Asset Classes
What to test: Does the backend confuse different asset types?
How to test:
- Send scam NFTs to an address expecting native tokens
- Test with rebase tokens, deflationary tokens, tokens with unusual decimals
- Send tokens with malicious metadata
Impact: Asset theft, platform exploitation
Testing Methodology
Phase 1: Reconnaissance
- Identify DApp architecture type (API-less, API-enabled, Full-scale)
- Map all endpoints and APIs
- Identify smart contracts involved (addresses, functions)
- Understand wallet integration (MetaMask, WalletConnect, etc.)
- Document all blockchain interactions
Phase 2: Client-Side Testing
- Test for XSS (critical in DApps - can manipulate wallet interactions)
- Check for content tampering opportunities
- Verify wallet interaction security
- Test transaction signing flows
- Review how transaction details are displayed to users
Phase 3: Backend/API Testing
- Test transaction handling endpoints
- Verify block confirmation logic (does it wait for confirmations?)
- Check for rate limiting on blockchain operations
- Test smart contract address validation
- Test asset type handling and validation
- Look for exposed private keys or admin credentials
Phase 4: Smart Contract Testing
- Review contract code for vulnerabilities
- Test event emission handling
- Verify asset type handling (ERC-20, ERC-721, native tokens)
- Check for reentrancy and other common issues
- Test with edge case tokens (rebase, deflationary, high decimals)
Phase 5: Integration Testing
- Test backend-blockchain synchronization
- Verify transaction confirmation flows
- Test race condition scenarios (withdrawal + purchase)
- Validate asset class handling across the stack
- Test failed/reverted transaction handling
Key Considerations
- Client-side vulnerabilities have amplified impact in DApps since clients perform blockchain operations
- Backend can be a single point of failure even in "decentralized" apps
- Transaction confirmation is critical - never assume immediate finality
- Asset type validation is essential - don't trust metadata or assume token types
- Gas costs can be weaponized - limit backend blockchain operations
- Wallet interactions are trust boundaries - users may not understand what they're signing
Quick Reference: Attack Vector Checklist
References
