Solidity Security Basics: Reentrancy, Access Control, and Common Bugs (Complete Guide)

A practical foundation for Solidity security

Most people learn Solidity by building features. Security requires a shift: you learn to build constraints. Instead of asking “how do I implement this,” you also ask “what could go wrong if someone tries to break this.” That second question is not paranoia, it is how you price reality. If a contract can be exploited, someone will do it. Sometimes it will be a sophisticated attacker. Sometimes it will be a bored user with a script. Either way, the outcome is the same.

Before we zoom into reentrancy and access control, lock down three non negotiable concepts:

Invariants you should be able to say out loud

An invariant is a sentence you can say that must remain true after every possible transaction. If your contract manages balances, one invariant might be “the sum of user balances equals the tracked total.” If your contract uses roles, an invariant might be “only role X can change parameter Y, and every change emits an event.” Invariants keep you honest because they force you to define what you are protecting.

When an exploit happens, it is usually because an invariant was violated. Sometimes the violation was obvious. Sometimes it was a subtle edge case in a callback or a token integration. Either way, you can often describe the incident in one line: a state update happened in the wrong order, a permission was too broad, or an assumption about an external contract was wrong.

Prerequisite reading you should not skip

This article focuses on reentrancy, access control, and common bugs. Two topics sit right next to them and amplify risk if misunderstood:

• Pausable Patterns in Smart Contracts: pause controls can save you during incidents, but they can also become censorship or hidden custody if designed poorly.
• How Upgradeable Smart Contracts Work: upgrades can fix bugs, but they also create a new attack surface and a governance trust model.

Keep those two posts in mind as you read. Reentrancy and access control do not live in a vacuum. They live inside systems with upgrade keys, pausers, multisigs, and sometimes rushed operational decisions.

How the EVM calling model creates security risks

The EVM is deterministic and simple, which is good. The complexity comes from composition. Contracts call other contracts. Tokens call back into your contract via hooks or fallback functions. Bridges and routers forward calls. Proxies delegate calls. A single transaction can create a deep call stack. Attackers thrive in this space because humans tend to reason linearly while control flow can loop back unexpectedly.

Message calls, state, and the moment you lose control

In Solidity, the dangerous moment is when you make an external call. That includes sending ETH, calling another contract interface, calling a token contract, or invoking a router. When your contract calls out, you are not just sending a message. You are handing execution to code you do not control.

The two questions that matter:

• Can the called contract call back into you before you finish your state changes?
• If it calls back, can it observe or manipulate a partially updated state?

If the answer can be “yes,” you must design for it. That design is what reentrancy protection really is.

Reentrancy: the vulnerability everyone mentions and many still misunderstand

Reentrancy is usually explained as “a contract calls you back and drains funds.” That is the famous version, but the real definition is broader and more useful: reentrancy is when your contract makes an external call and that external call regains control before your function finishes. If your logic is not designed for that possibility, an attacker can exploit the time window between “you decided what should happen” and “you finalized state.”

This is why reentrancy remains relevant even as Solidity and tooling improve. It is not a compiler issue. It is a design issue, and it shows up anywhere you combine stateful logic with external calls.

The three flavors you actually see in audits

In the real world, reentrancy does not always look like a simple ETH withdraw. Here are three categories that help you spot it early:

• Value reentrancy: the classic case where a withdraw or transfer can be repeated before balances update.
• Logic reentrancy: the attacker cannot drain directly but can call functions in an unexpected order to bypass limits, pricing, or checks.
• Cross function reentrancy: you protect one function but an attacker reenters through another function that shares mutable state.

The last one is the most dangerous for teams that add a reentrancy modifier to a single function and assume the problem is solved. If multiple functions read and write shared state, you must reason at the contract level, not per function.

A minimal vulnerable pattern

The goal here is not to teach you a toy example. It is to train your eyes. When you see “external call before state update,” you should feel discomfort.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VaultBad {
  mapping(address => uint256) public balance;

  function deposit() external payable {
    balance[msg.sender] += msg.value;
  }

  function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount, "insufficient");

    // DANGER: external call before state update
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "send failed");

    // State update happens after external interaction
    balance[msg.sender] -= amount;
  }
}

What makes this vulnerable is not the use of call alone. It is the order. If msg.sender is a contract with a fallback function, it can call withdraw again before the first call finishes. On the second entry, the balance is still unchanged, so the require passes again. This repeats until the vault is drained or gas runs out.

How the attacker actually exploits it

An attacker contract deposits a small amount, then calls withdraw. In its fallback function, it calls withdraw again. The vault sends value again. The attacker loops until the vault is empty.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IVaultBad {
  function deposit() external payable;
  function withdraw(uint256 amount) external;
}

contract ReenterAttacker {
  IVaultBad public vault;
  uint256 public step;

  constructor(address vaultAddr) {
    vault = IVaultBad(vaultAddr);
  }

  function attack() external payable {
    require(msg.value > 0, "need seed");
    vault.deposit{value: msg.value}();
    vault.withdraw(msg.value);
  }

  receive() external payable {
    // Keep reentering while vault can still pay
    step++;
    if (address(vault).balance >= 1 wei) {
      // attempt to withdraw the same amount again
      vault.withdraw(msg.value);
    }
  }
}

In real incidents, attackers tune the loop, the amount, and the gas to optimize extraction and avoid reverts. They may combine this with other issues like price manipulation or unsafe accounting. That is why the right response is not “do not use call.” The right response is “design so callbacks cannot violate invariants.”

Fixing reentrancy the right way

There are three core strategies that cover most cases. You can combine them depending on your product needs.

1) Checks-Effects-Interactions

Checks-Effects-Interactions (CEI) is the first principle of Solidity safety. You do your validation, then you update internal state, then you interact externally. This makes reentrancy far less useful because by the time control leaves your contract, the internal state reflects the new reality.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract VaultCEI {
  mapping(address => uint256) public balance;

  function deposit() external payable {
    balance[msg.sender] += msg.value;
  }

  function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount, "insufficient");

    // Effects first
    balance[msg.sender] -= amount;

    // Interactions last
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "send failed");
  }
}

CEI prevents the classic drain, but it does not magically solve every reentrancy scenario. If other shared state exists, or if there are multiple functions that can be reached during reentry, you still need to reason about the whole contract.

2) Reentrancy guards

A guard is a simple lock that prevents reentering protected functions during an active call. This is useful when the contract has complex shared state and you want a clear, enforceable rule: “no nested entry.”

Many teams use OpenZeppelin’s ReentrancyGuard for this, but the concept can also be implemented manually. The important part is scope: a guard only protects functions that use it, and it does not protect you if the dangerous path is reachable elsewhere.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

abstract contract SimpleReentrancyGuard {
  uint256 private locked = 1;

  modifier nonReentrant() {
    require(locked == 1, "reentrant");
    locked = 2;
    _;
    locked = 1;
  }
}

contract VaultGuarded is SimpleReentrancyGuard {
  mapping(address => uint256) public balance;

  function deposit() external payable {
    balance[msg.sender] += msg.value;
  }

  function withdraw(uint256 amount) external nonReentrant {
    require(balance[msg.sender] >= amount, "insufficient");
    balance[msg.sender] -= amount;
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "send failed");
  }
}

If you are building a vault, a DEX, or a protocol with multiple state transitions, guards often make sense. If you are building a simple escrow, CEI and pull payments can be enough. The best choice depends on complexity and how many external calls exist.

3) Pull payments and claim patterns

Push payments are when you send funds during the same function that updates state. Pull payments are when you record what someone can claim, and they claim later in a separate call. Pull patterns reduce the amount of complex logic that happens during a single call, and they reduce the blast radius of an external call.

A common secure pattern: finalize business logic and record a claimable amount, then have a dedicated claim() function that only does CEI and the transfer. This keeps the rest of your protocol simpler and makes audits easier.

Important: reentrancy is not only ETH transfers

Teams sometimes apply reentrancy thinking only to ETH withdraw functions. That is a mistake. Reentrancy can show up when you call:

• ERC777 tokens that have hooks and can call back.
• Routers and aggregators that can execute arbitrary targets.
• External price oracles or callbacks in complex systems.
• Any untrusted contract interface, including “safe” tokens with nonstandard behaviors.

The better mindset is: any external call is a potential reentrancy boundary. You either design your state transitions to be safe under reentry, or you prevent reentry.

Access control: permissions are product design

If reentrancy is about control flow, access control is about authority. Authority in Solidity is not a vibe, it is a function modifier. If you accidentally give someone the ability to change fees, mint tokens, pause transfers, or upgrade implementation code, you have effectively created a custody system that can be abused or compromised.

A secure protocol does not just “have access control.” It has a clear permission story that can be explained to users: who can do what, under what constraints, with what visibility, and with what recovery process.

Think in layers: users, operators, and governance

Access control becomes easier when you stop thinking in a single admin role. Most real systems need multiple roles with different scopes:

• User permissions: what any user can do, plus what a user can do on behalf of another user (approvals, signatures).
• Operator permissions: limited roles for maintenance, relays, or automation, ideally with narrow scope.
• Governance permissions: rare, high impact changes like upgrades, parameter changes, or emergency stops, ideally timelocked.

If you collapse all these into a single owner, you might ship faster, but you will also carry a larger attack surface and a worse trust model. Even if you fully trust your team, compromise is still possible. Your design should assume that.

Ownable is a starting point, not a complete system

Ownable is useful for prototypes and small scope contracts. For serious systems, you often need roles and separation of duties. A single owner key is a single point of catastrophic failure.

A more robust pattern is role based access control: different roles for pausing, upgrading, fee configuration, and treasury operations. Even then, roles must be paired with governance constraints such as timelocks and transparency.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract RolesExample {
  mapping(bytes32 => mapping(address => bool)) internal hasRole;

  bytes32 public constant ROLE_GUARDIAN = keccak256("ROLE_GUARDIAN");
  bytes32 public constant ROLE_GOVERNANCE = keccak256("ROLE_GOVERNANCE");
  bytes32 public constant ROLE_OPERATOR = keccak256("ROLE_OPERATOR");

  event RoleGranted(bytes32 indexed role, address indexed account);
  event RoleRevoked(bytes32 indexed role, address indexed account);

  modifier onlyRole(bytes32 role) {
    require(hasRole[role][msg.sender], "missing role");
    _;
  }

  function _grant(bytes32 role, address account) internal {
    hasRole[role][account] = true;
    emit RoleGranted(role, account);
  }

  function _revoke(bytes32 role, address account) internal {
    hasRole[role][account] = false;
    emit RoleRevoked(role, account);
  }

  // Example: guardian can pause, governance can unpause
  bool public paused;

  function pause() external onlyRole(ROLE_GUARDIAN) {
    paused = true;
  }

  function unpause() external onlyRole(ROLE_GOVERNANCE) {
    paused = false;
  }
}

Notice the design choice: guardians can pause but cannot unpause. That is a separation of duties pattern. It reduces the chance a compromised guardian can permanently lock the system. This is exactly why the pausable topic matters and why it is worth reading Pausable Patterns in Smart Contracts.

Timelocks: turning power into a process

Timelocks are one of the most practical safety mechanisms in DeFi governance. If a privileged role can change critical parameters, a timelock gives users time to react. It also gives the community time to review changes, and it reduces the benefit of instant malicious upgrades.

Timelocks do not make a system “trustless,” but they improve the trust model. They turn “admins can do anything instantly” into “admins can do anything with delay and visibility.” That difference is massive in practice.

Access control and upgrades are joined at the hip

Many modern systems are upgradeable, whether via transparent proxies, UUPS proxies, beacons, or custom patterns. Upgrades are permissions on steroids. If the upgrade role is compromised, the contract logic can be replaced entirely. That is why you should treat upgrade keys as a separate class of risk, and why the prerequisite post on upgradeability matters: How Upgradeable Smart Contracts Work.

A strong baseline approach for upgrades:

• Use a timelock for upgrade execution.
• Separate propose and execute roles where possible.
• Emit clear events and publish upgrade notices.
• Use conservative emergency controls with narrow scope.
• Document the trust model so users are not surprised.

Common Solidity bugs that keep showing up

This section is deliberately practical. These are issues that audits still find, and attackers still exploit. Some are “classic” vulnerabilities. Some are integration hazards. The goal is for you to recognize patterns before they become incidents.

Bug class: using tx.origin for authentication

tx.origin is the original external account that started the transaction. It is almost never correct to use it for authorization. If you require tx.origin == owner, an attacker can trick the owner into calling a malicious contract that then calls your contract. Your contract sees the owner as tx.origin, and the attacker’s contract as msg.sender. If you used msg.sender, the call would fail. If you used tx.origin, the call may pass.

Bug class: unchecked return values from low level calls

In Solidity, low level calls like call, delegatecall, and staticcall return a boolean success value. If you ignore it, your contract might assume something happened when it did not. That can break accounting or open bypasses.

Even more common: ERC20 tokens are not perfectly standardized in behavior across the ecosystem. Some tokens do not return booleans the way you expect. Some revert. Some return false. If you integrate tokens, use safe wrappers that handle these cases.

Bug class: approval and allowance pitfalls

Many DeFi protocols rely on allowances and token approvals. The pitfalls:

• Infinite approvals: convenient for UX, but increases loss if a spender contract is compromised.
• Approval race conditions: changing an allowance from A to B can be abused in older token patterns unless handled carefully.
• Permit misuse: signature based approvals reduce friction but must be validated with strict domain separation.

For users, a security habit is to review allowances and revoke unused ones. For builders, a security habit is to minimize reliance on broad approvals and to document spender risks. If you are evaluating a token or a contract in the wild, a fast sanity scan of risk signals helps. That is a good use case for Token Safety Checker.

Bug class: arithmetic mistakes and unit confusion

Solidity 0.8+ includes built in overflow and underflow checks by default, which removed an entire historical class of bugs. But arithmetic mistakes still happen, mostly due to unit confusion and rounding. Examples:

• Mixing token decimals and assuming 18 decimals for everything.
• Using integer division in pricing or reward math and unintentionally rounding down to zero.
• Computing shares and withdrawing value with mismatched rounding directions, leaking funds over time.
• Assuming fixed point math without using a dedicated library and clear scaling factors.

These bugs rarely look dramatic in a unit test. They become expensive after weeks of compounding. The defense is to define invariants and test them. If you cannot define the expected relationship between totals and balances, you will miss these.

Bug class: price manipulation and oracle assumptions

Many contracts depend on price inputs. The most common failure mode is assuming the price is honest because it comes from “a DEX” or “an oracle.” Attackers can manipulate DEX prices with flash liquidity. Oracles can be delayed or compromised. Updates can be stale.

Practical defenses include:

• Use time weighted average prices where appropriate.
• Validate freshness and bounds.
• Use multiple sources or circuit breakers for extreme moves.
• Design so price manipulation is expensive relative to maximum extractable profit.

Bug class: delegatecall and storage collision

delegatecall runs code from another contract in the storage context of your contract. This is powerful and dangerous. Proxies rely on it. Modular systems rely on it. The security risks:

• Storage collision: if the called code expects storage layout A but your contract has layout B, you can corrupt state.
• Arbitrary execution: if an attacker can control the delegatecall target, they can execute arbitrary logic with your contract’s storage.
• Upgrade risks: a bad implementation upgrade can brick the proxy or open new backdoors.

If you are using proxies, do not treat the upgrade role as “just admin.” It is effectively root access. Revisit the upgradeable contracts guide for a deeper mental model: How Upgradeable Smart Contracts Work.

Bug class: uninitialized contracts and missing initializer protection

In proxy systems, constructors do not run the way you think. Initializers replace constructors. If you deploy an implementation contract and forget to lock it, someone may initialize it and take ownership. If you forget to initialize the proxy properly, someone else might do it.

A simple safety rule: implementation contracts should be initialized to a locked state (or have initializers disabled) so nobody can claim ownership of the implementation itself. Proxies should be initialized atomically in deployment.

Bug class: denial of service via gas or revert behavior

Not all attacks steal funds. Some attacks prevent you from operating. DoS appears when:

• You loop over a growing list and the loop becomes too expensive.
• You depend on an external contract that can revert and block your function.
• You attempt to send ETH to a contract that always reverts, blocking payouts.
• You allow unbounded user input that expands work.

Defensive patterns include: pagination, pull payments, bounded loops, and careful external call handling. If an external call can revert, consider isolating it so it cannot block critical state transitions.

A repeatable security workflow you can run on any contract

“Be careful” is not a workflow. A workflow is a series of steps that produces a predictable improvement in safety. Here is a security workflow you can reuse, whether you are reviewing your own code or auditing a third-party contract.

Step 1: Write the threat model in plain English

A threat model answers:

• What assets are at risk? Tokens, ETH, governance control, user data, reputation?
• Who are the adversaries? Anyone, sophisticated MEV bots, privileged insiders, compromised admins?
• What are the attack surfaces? External calls, upgrades, role gated functions, token hooks, oracles?
• What is the worst credible outcome? Total loss, partial loss, temporary lock, censorship?

This is not paperwork. It is how you decide what deserves defensive design and what is acceptable risk.

Step 2: Identify state changes and external call boundaries

Mark every line where:

• Storage is written.
• External calls happen (including token transfers and router calls).
• Control can be transferred (callbacks, hooks, fallback, delegatecalls).

Then check for unsafe ordering: external calls before state updates, or mixed shared state across multiple entry points. This step alone catches a large portion of reentrancy and logic bugs.

Step 3: Define invariants and test them

For each subsystem, define invariants. Examples:

• Accounting: totals match balances under all deposit and withdraw sequences.
• Limits: per address caps cannot be bypassed by reentry or cross function ordering.
• Permissions: only role X can call Y, and role changes emit events.
• Pausing: when paused, sensitive actions are blocked while safe actions remain possible.

Write tests that attempt to break invariants with weird ordering and hostile inputs. If you have time, add property based tests and fuzzing. If you do not, still write adversarial unit tests. Most teams fail at this step not because they lack tools, but because they did not define invariants clearly.

Step 4: Run a checklist review that enforces habits

A checklist is valuable when it is short, consistent, and used every time. Here is a high signal checklist that maps directly to reentrancy, access control, and common bugs.

Step 5: Use tooling without outsourcing thinking

Static analyzers and scanners are useful. They are not substitutes for reasoning. A good workflow uses tools to:

• Find pattern based issues quickly (like reentrancy suspects and unsafe calls).
• Highlight dead code, unused variables, shadowing, and suspicious constructs.
• Cross check assumptions against known classes of bugs.

The best outcome is when tools confirm your reasoning, not when tools replace it.

Step 6: Deployment and operational hygiene

Many incidents are not “coding errors.” They are operational mistakes:

• Wrong addresses passed to initialization.
• Forgotten timelocks, or timelocks set to zero.
• Admin keys stored insecurely, or multisig signers compromised.
• Upgrades executed without review windows.

If you use upgrade patterns, treat upgrades like releases in aerospace: gated, reviewed, and observable. If you use pause patterns, define rules for when pausing is allowed, who can do it, and how unpausing works. That is why the prerequisite reading matters and why you should revisit it before mainnet: Pausable Patterns in Smart Contracts and How Upgradeable Smart Contracts Work.

Practical scenarios and how these bugs appear in real systems

It is easier to internalize security when you see how issues combine. Most incidents are not a single mistake. They are a chain of mistakes that amplify each other. Below are realistic scenarios and what to watch for.

Scenario: a vault with deposits, withdrawals, and reward harvesting

Vaults often have:

• Deposit and withdraw functions.
• Accounting for shares.
• Reward harvesting that calls external contracts.
• Emergency withdrawal paths.

The reentrancy risk is not only in withdraw. It can appear in harvest functions that call routers, reward contracts, or tokens with hooks. The access control risk appears in who can set strategy addresses, fee recipients, or pause conditions. The common bug risk appears in rounding, token decimals, and unsafe external call handling.

A secure design usually has:

• Clear CEI ordering in state changes.
• Guards around functions that interact with external contracts.
• Separation between user functions and operator functions, with minimal operator scope.
• Events for all parameter changes and operational actions.

Scenario: a DEX or AMM with callbacks

Some DEX designs involve callback patterns where the pool calls the trader contract, or where flash swaps allow execution mid trade. This is a reentrancy playground. If your protocol integrates with such systems, you must assume complex control flow.

The secure strategy is to:

• Minimize mutable shared state during external callbacks.
• Use guards where appropriate, but do not rely only on them.
• Assert invariants explicitly after callbacks return.

Scenario: auctions, mints, and allowlists

Mints and auctions often fail on access and assumptions:

• Incorrect allowlist verification.
• Mispriced mint due to decimals or integer division.
• Refund paths that send ETH and create reentrancy windows.
• Admin functions that can change parameters without timelocks.

A safe refund path is often a pull pattern: track refunds and let users claim them. A safe allowlist uses verified proofs and strict domain separation for signatures.

A simple maturity model for Solidity security

Security is a spectrum. You do not go from beginner to perfect in one release. A maturity model helps you understand what to improve next.

If you are serious about building your skills, combine structured learning with repetition. Use Blockchain Technology Guides for fundamentals and Blockchain Advance Guides for deeper system-level understanding. If you want ongoing playbooks and security notes, consider Subscribe.

A visual: how small mistakes turn into large losses

One reason security feels hard is that the impact curve is not linear. A tiny bug can have an enormous consequence because the chain is public, composable, and adversarial. The chart below is a simplified mental model. It is not “math,” it is intuition.

Tools and habits that make security sustainable

Security is easier when it is part of daily workflow, not a once-per-release scramble. Below are tools and habits that map to real outcomes.

Structured learning and repeatable practice

A fast way to grow skill is to learn concepts in order and apply them repeatedly. Use Blockchain Technology Guides to lock down fundamentals, then reinforce system risks in Blockchain Advance Guides.

If your goal is “ship safer code,” you want repetition more than novelty. Review one contract per week with the checklist in this article, and you will build instinct. That instinct is what prevents incidents.

On-chain monitoring and investigation

When you ship contracts, your job is not finished. You want to detect anomalies: unusual flows, suspicious approvals, abnormal transaction patterns, and sudden changes in behavior. For deeper wallet and smart money analysis, tools like Nansen can be relevant in a security workflow, especially for monitoring token distribution, wallet clusters, and behavior shifts.

For quick contract and token risk signals, keep a fast path: Token Safety Checker. The point is not to outsource judgment. The point is to reduce the time between “something feels off” and “I have evidence.”

Personal security hygiene for builders and power users

Your code can be perfect and you can still lose funds if your keys are compromised. If you deploy contracts, sign upgrades, or manage treasuries, you should use hardware wallets and clean operational setups. A practical step is to use a hardware wallet like Ledger for signing critical transactions.

Hardware wallets do not solve everything, but they significantly reduce the risk of malware draining keys from a hot wallet. Combine them with multisigs, safe signer hygiene, and clear operational policies.

A fast playbook you can run before shipping

If you are close to shipping and you want a last-mile safety pass, run this playbook. It is not a substitute for an audit, but it catches a surprising amount of risk.

If you are using pausing or upgrades, do not treat them as last-minute toggles. They change your system’s trust model. That is why you should revisit prerequisite reading before mainnet and again as part of post-launch maintenance: Pausable Patterns in Smart Contracts and How Upgradeable Smart Contracts Work.

FAQs

References

Official documentation and reputable sources for deeper reading:

• Solidity Documentation
• SWC Registry (Smart Contract Weakness Classification)
• OpenZeppelin Contracts Documentation
• Ethereum Improvement Proposals (EIPs)
• Ethereum.org: Smart contract security
• TokenToolHub: Pausable Patterns in Smart Contracts
• TokenToolHub: How Upgradeable Smart Contracts Work
• TokenToolHub: Token Safety Checker
• TokenToolHub: Blockchain Technology Guides
• TokenToolHub: Blockchain Advance Guides

Final reminder: Solidity security is not one trick. It is a system of habits: treat external calls as hostile boundaries, design permissions as blast radius problems, enforce invariants through adversarial testing, and make upgrades and emergency controls transparent and constrained. Revisit prerequisite reading regularly because these topics amplify each other in production: Pausable Patterns in Smart Contracts and How Upgradeable Smart Contracts Work. For ongoing playbooks, you can Subscribe.