30 Common Security Mistakes Solidity Developers Make (And How to Avoid Them)

What happens: The DAO hack ($60M), Cream Finance ($130M), and countless others exploited this exact pattern.

Fix: Always use checks-effects-interactions pattern AND ReentrancyGuard. Update all state before external calls.

What happens: Failed transfers silently succeed, leading to accounting errors and fund loss.

Fix: Always check return values: (bool success, ) = addr.call{value: amount}(""); require(success);

What happens: Attackers use flashloans to manipulate prices within a single transaction. Hundreds of millions lost.

Fix: Use Chainlink or other decentralized oracles. For AMM prices, use TWAP with sufficient window.

What happens: Anyone can call privileged functions, drain funds, or take over the contract.

Fix: Use OpenZeppelin's AccessControl or Ownable2Step. Audit every external/public function.

What happens: Attackers call initialize() and become owner. Wormhole lost $320M to a variant of this.

Fix: Call _disableInitializers() in the constructor and ensure initialize is called during deployment.

What happens: Attacker executes malicious code in your contract's context, taking full control.

Fix: Never delegatecall to addresses that users can influence. Whitelist allowed targets.

What happens: Phishing attacks can trick users into calling malicious contracts that relay to yours.

Fix: Always use msg.sender for authorization. tx.origin should almost never be used.

What happens: Sandwich attacks extract value from every transaction. Users lose to MEV bots.

Fix: Add minAmountOut parameters to all trading functions. Let users set their slippage tolerance.

What happens: Overflows wrap around, allowing attackers to create tokens from nothing or bypass checks.

Fix: Use Solidity 0.8+ or SafeMath for all arithmetic. Be careful with unchecked blocks.

What happens: Attackers claim multiple times or claim on behalf of others.

Fix: Hash leaves with abi.encodePacked(msg.sender, amount) and mark claimed addresses.

What happens: Transfers to contracts with receive() functions that need more gas will fail permanently.

Fix: Use .call{value: amount}("") with reentrancy protection instead.

What happens: Functions become unusable after gas repricing, potentially locking funds.

Fix: Avoid hardcoded gas values. Test with different gas prices and EVM versions.

What happens: Large values get truncated, leading to incorrect calculations and potential exploits.

Fix: Use SafeCast library or explicit bounds checking before downcasting.

What happens: Funds sent to zero address are burned. Ownership set to zero address locks the contract.

Fix: Add require(addr != address(0)) for all address parameters in setters and constructors.

What happens: Valid signatures can be replayed, allowing unauthorized actions.

Fix: Use EIP-712 with chainId and per-user nonces. Increment nonce after each use.

What happens: Miners can manipulate timestamp by several seconds, affecting outcomes.

Fix: Use block numbers for precision. Allow ~15 second tolerance for timestamp-based logic.

What happens: Attacker front-runs and spends both old and new allowance.

Fix: Use increaseAllowance/decreaseAllowance or set to 0 first, then new value.

What happens: Array grows until processing exceeds block gas limit, permanently bricking the contract.

Fix: Use pagination, caps, or pull patterns instead of push patterns with loops.

What happens: Wrong implementation gets called, potentially bypassing security checks.

Fix: List base contracts from most base-like to most derived. Test inheritance carefully.

What happens: Variables point to wrong storage slots, leading to data corruption and exploits.

Fix: Only append new variables. Use storage gaps. Run upgrade-safety checks.

What happens: Contract may compile with untested compiler version introducing bugs.

Fix: Lock pragma to specific version you've tested: pragma solidity 0.8.20;

What happens: Makes monitoring and debugging difficult. Hides malicious admin actions.

Fix: Emit events for all state changes, especially in admin functions.

What happens: Wastes gas and signals lack of attention to detail in security reviews.

Fix: Use external for functions only called from outside. Reserve public for internal calls.

What happens: May miss important status information or error conditions.

Fix: Either use the return value or explicitly discard: (, uint b) = func();

What happens: Makes auditing harder, increases chance of misuse by integrators.

Fix: Add @notice, @param, @return, and @dev tags to all external functions.

What happens: Signature malleability can lead to duplicate valid signatures.

Fix: Use OpenZeppelin's ECDSA library which handles all edge cases.

What happens: assert uses all remaining gas. Confuses intention of error handling.

Fix: Use require for input validation, assert only for invariants, custom errors for gas efficiency.

What happens: Makes code harder to audit and maintain. Easy to introduce errors.

Fix: Define constants: uint256 constant BASIS_POINTS = 10000;

What happens: Some tokens don't return bool, causing transfers to fail silently.

Fix: Use OpenZeppelin's SafeERC20 for all token interactions.

What happens: Warnings often indicate real issues that could become vulnerabilities.

Fix: Treat warnings as errors. Resolve all warnings before deployment.