← Back to Blog
Blockchain11 min read

Web3 Security: Common Smart Contract Vulnerabilities and How to Avoid Them

NDN Analytics TeamApril 13, 2026

The Web3 space moves fast — too fast for security sometimes. In 2025, smart contract vulnerabilities and exploits cost the blockchain ecosystem over $14 billion. Many of these losses were preventable.


This isn't fear-mongering. It's a call for defensive engineering.


Why Smart Contract Security Matters


Smart contracts are immutable. Once deployed, you can't patch a vulnerability like you can in traditional software. A bug in production is a bug forever — unless you can convince the ecosystem to fork the chain.


For enterprise blockchain use cases (supply chain, payments, credentials), security isn't an option. It's a prerequisite.


The Top 8 Smart Contract Vulnerabilities


### 1. **Reentrancy**

A function that makes an external call to an untrusted contract before updating internal state can be exploited.


**Example:** A lending contract withdraws funds before updating the balance. An attacker contract re-enters the function and withdraws again.


**Defense:**

  • Use the "checks-effects-interactions" pattern: verify state, make changes, then make external calls
  • Implement a reentrancy guard (OpenZeppelin provides battle-tested implementations)
  • Verify all external calls before state changes

    • ### 2. **Integer Overflow/Underflow**

    Integers in Solidity have fixed sizes. Exceeding the maximum or going below zero wraps around.


    **Example:** Subtracting from a zero balance results in a maximum uint256 value (instead of reverting).


    **Defense:**

  • Use Solidity 0.8.0+, which has built-in overflow protection
  • For older contracts, use SafeMath library
  • Set upper/lower bounds on token amounts

    • ### 3. **Unchecked Call Return Values**

    Function calls return a boolean success value. If you don't check it, failures are silently ignored.


    **Example:** transfer() returns false if it fails, but the contract continues as if it succeeded.


    **Defense:**

  • Always check return values: require(token.transfer(recipient, amount), "Transfer failed")
  • Prefer safeTransfer() from OpenZeppelin (reverts instead of returning false)

    • ### 4. **Access Control Flaws**

    Missing or incorrect permission checks allow unauthorized users to execute admin functions.


    **Example:** A contract has an emergencyWithdraw() function with no onlyOwner modifier — anyone can drain it.


    **Defense:**

  • Use OpenZeppelin's Ownable or AccessControl for permission management
  • Default to deny, explicitly grant permissions
  • Test with different roles (owner, user, attacker)

    • ### 5. **Front-Running**

    Transactions are visible in the mempool before execution. An attacker can see your transaction, submit their own with higher gas, and execute first.


    **Example:** You submit a swap on a DEX. An attacker sees it, submits an identical swap with higher gas, moving the price against you.


    **Defense:**

  • Use private mempools (Flashbots Protect)
  • Implement slippage protections (max acceptable price change)
  • Use batch auctions or MEV-resistant DEXs
  • For sensitive transactions, encrypt inputs

    • ### 6. **Flash Loan Attacks**

    A flash loan allows you to borrow massive amounts without collateral, but you must repay (plus fees) within the same transaction. Attackers exploit this to manipulate prices.


    **Example:** Borrow $100M in tokens, manipulate a price oracle, execute a trade that profits from the manipulated price, repay the loan.


    **Defense:**

  • Never use a single source for price oracle (Uniswap, Chainlink, etc.)
  • Use time-weighted averages instead of spot prices
  • Add minimum holding periods for sensitive operations
  • Implement circuit breakers that pause trading if prices move >X% in Y blocks

    • ### 7. **Delegatecall Vulnerabilities**

    delegatecall allows one contract to execute another's code in its own storage context. If misused, an attacker can modify storage.


    **Example:** A proxy contract uses delegatecall to forward calls to an implementation contract. The implementation contract has selfdestruct() — goodbye to the proxy.


    **Defense:**

  • Avoid delegatecall unless you understand the implications
  • For proxies, use battle-tested patterns (UUPS, Transparent Proxy)
  • Ensure implementation contracts can't be called directly (make constructor revert)
  • Use OpenZeppelin's proxy contracts

    • ### 8. **Insufficient Input Validation**

    Lack of validation on input parameters allows invalid states.


    **Example:** A contract accepts a discount percentage without validating it's <100%. Someone submits 1000%, contract mints fake tokens.


    **Defense:**

  • Validate all inputs: ranges, types, formats
  • Use require() statements liberally
  • Test with edge cases: zero, maximum uint256, negative numbers

    • The NDN Analytics Security Approach


    At NDN, we build blockchain systems for regulated industries where security is non-negotiable. Our smart contracts used in NDN TraceChain, NDN PayStream, NDN CredVault, and Njangi follow these practices:


    ### Development Standards

  • Solidity 0.8.0+** with built-in overflow protection
  • OpenZeppelin contracts** for proven implementations
  • Formal verification** for critical functions
  • Multi-sig governance** for upgrade authority

    • ### Testing & Auditing

  • 100% code coverage with unit tests
  • Fuzzing tests for edge cases
  • Third-party security audits (Quantstamp, Trail of Bits)
  • Mainnet deployments only after testnet validation

    • ### Monitoring & Response

  • Real-time contract monitoring for anomalous behavior
  • Pause mechanisms for emergency situations
  • Multi-signature requirements for critical operations
  • Transparent incident response (disclosure within 24 hours)

    • Building Secure Blockchain Systems


    If you're deploying a blockchain system — whether supply chain, payments, credentials, or community finance — security must be designed in, not bolted on.


    **The cost of fixing a vulnerability in production is 100x the cost of finding it before deployment.**


    ### What We Recommend

  • **Start with proven patterns**: Use OpenZeppelin, Compound, Uniswap as references — not novel approaches
  • **Test exhaustively**: Automated tests + fuzzing + manual code review
  • **Get audited**: Third-party security firm, not internal review
  • **Monitor in production**: Anomaly detection, circuit breakers, pause mechanisms
  • **Plan for incidents**: Assume you'll find bugs. Have an emergency response plan.

    • Getting Started Securely


    If you're evaluating blockchain solutions for supply chain, payments, or Web3 applications, security is the first question.


    Schedule a technical assessment with NDN — we'll evaluate your security requirements and design a solution that's bulletproof.

    Need Help Implementing AI/Blockchain Solutions?

    NDN Analytics specializes in enterprise AI and blockchain implementation. Our team can help you integrate cutting-edge technology into your existing workflows.