Home/Blockchain/Reentrancy Attack Simulator/Prevention Methods

🔒 Checks-Effects-Interactions: Preventing Reentrancy

Master reentrancy guards, mutex locks, and the CEI pattern

Your Progress

0 / 5 completed

🛡️ Preventing Reentrancy Attacks

Now that you understand how reentrancy attacks work, let's explore the battle-tested methods developers use to protect their smart contracts.

🎯 Interactive: Prevention Methods

Explore 4 proven techniques to prevent reentrancy attacks:

📋

Checks-Effects-Interactions

Basic

Fundamental pattern: check conditions, update state, then call externally

Effectiveness

95%

Gas Impact

None

Implementation

Change code order

Pattern Order:

1. Checks ✓

Validate all conditions

2. Effects 📝

Update contract state

3. Interactions 🔗

Make external calls

🎯 Interactive: Code Pattern Comparison

See the difference between vulnerable and secure implementations:

❌ Vulnerable: External Call Before State Update

function withdraw(uint amount) external {
  // ✅ Check condition
  require(balances[msg.sender] >= amount, "Insufficient balance");
  
  // ❌ DANGER: External call before state update
  (bool success, ) = msg.sender.call{value: amount}("");
  require(success, "Transfer failed");
  
  // ❌ TOO LATE: State update after external call
  // Attacker can reenter before reaching here
  balances[msg.sender] -= amount;
  
  emit Withdrawal(msg.sender, amount);
}

🚨 Problems:

• Balance check passes on reentry (balance unchanged)
• Attacker withdraws multiple times
• Contract drained before balance update

Best Practices Checklist

✅

Always use ReentrancyGuard

Import OpenZeppelin's ReentrancyGuard and add nonReentrant modifier to functions with external calls.

✅

Follow Checks-Effects-Interactions

Order matters: validate inputs, update state, then make external calls. Never reverse this order.

✅

Use transfer() or send() for simple ETH transfers

These methods have 2,300 gas limit, preventing complex reentrancy. Only use call when necessary.

✅

Consider Pull Payment Pattern

Let users withdraw funds rather than pushing payments. Eliminates external calls from core logic.

✅

Audit external calls carefully

Every external call is a potential attack vector. Document why each is necessary and ensure proper guards.

✅

Test with reentrancy attack simulations

Write test cases that attempt reentrancy. If tests pass, your contract is vulnerable!

Common Mistakes to Avoid

❌

Trusting External Contracts

Never assume external contracts are safe. Always use guards even with "trusted" addresses.

❌

Incomplete State Updates

Update ALL related state before external calls, not just the obvious variable.

❌

Only Checking Direct Reentrancy

Cross-function reentrancy is harder to spot. Protect all functions that share state.

❌

Forgetting Fallback Functions

Remember that receive() and fallback() can contain attack code.

💡 Pro Tips

🔍

Use static analysis tools: Tools like Slither, Mythril, and Securify can detect reentrancy vulnerabilities automatically.

📚

Learn from audits: Read public audit reports to see how professionals identify and fix reentrancy issues.

🧪

Write attack contracts: Build malicious contracts in your tests to verify your defenses actually work.