Home/Blockchain/Security Best Practices Game/Common Vulnerabilities

Previous Module

Cross-chain Bridge Visual

⚠️ Common Vulnerabilities: Reentrancy & More

Understand the top 10 smart contract attack vectors

Protect your dApp from common vulnerabilities

Your Progress

0 / 5 completed

Introduction

Common Vulnerabilities

Secure Patterns

Testing & Auditing

Key Takeaways

🐛 Vulnerability Catalog

Beyond the big four (reentrancy, overflow, access control, front-running), production contracts face dozens of subtle vulnerabilities. Logic errors from incorrect assumptions. External call risks where malicious contracts manipulate your state. Gas-related attacks that lock contracts by hitting block limits. DoS vectors where griefers break core functionality. This section catalogs 14 common vulnerabilities with code examples, exploitation techniques, and fixes. Recognizing these patterns is the first step to writing secure contracts.

🎮 Interactive: Vulnerability Database

Browse vulnerabilities by category. Each includes vulnerable code, exploitation method, and secure fix.

🧩

Logic Errors

Business logic flaws and incorrect assumptions

Timestamp Dependence

Medium

Using block.timestamp for critical logic—miners can manipulate ±15 seconds

// ❌ Vulnerable
function claim() public {
  require(block.timestamp > deadline);
  // Miner can manipulate within 15s window
}

✅ Fix

Use block.number instead, or accept timestamp manipulation risk for non-critical logic.

Unchecked Return Values

High

Ignoring return values from external calls—silent failures

// ❌ Vulnerable
token.transfer(recipient, amount);
// If transfer fails, execution continues

✅ Fix

require(token.transfer(...), "Transfer failed") or use SafeERC20 library.

Race Conditions

Medium

Multiple transactions can manipulate state in unexpected order

// ❌ Vulnerable
function approve(uint amount) { allowance = amount; }
function transferFrom() { /* uses allowance */ }
// Attacker frontuns approve() to drain old + new allowance

✅ Fix

Use increaseAllowance/decreaseAllowance pattern instead of approve().

Default Visibility

Critical

Functions without visibility—public by default in old Solidity

// ❌ Vulnerable (Solidity <0.5)
function withdraw() { /* no visibility = public! */ }

✅ Fix

Always explicitly declare function visibility: public, external, internal, private.

🎮 Interactive: Attack Simulation

Step through a reentrancy attack in real-time. See how the exploit unfolds step-by-step.

⚡

Step 1 of 4

Attacker deploys malicious contract

Contract deployed with fallback function

🎯 Prevention Checklist

✓ Checks-Effects-Interactions

1. Validate inputs 2. Update state 3. External calls last

✓ Use ReentrancyGuard

OpenZeppelin modifier prevents nested calls

✓ Pull Over Push

Let users withdraw funds, don't push to them

✓ Explicit Visibility

Always declare public/external/internal/private

✓ Check Return Values

Never ignore call(), transfer(), delegatecall() results

✓ Avoid Loops on Unbounded Data

Limit array sizes or use pull pattern