If your smart contract has a function that moves money, mints tokens, or changes ownership, one question matters more than anything else: who is allowed to call it? Access control vulnerabilities are the number one cause of smart contract exploits, responsible for over $953 million in losses according to the OWASP Smart Contract Top 10 for 2025. A single missing permission check can turn a deploy into a disaster.
What is access control, in plain English
Think of access control like the key card system in an office building. The front door lets everyone in during business hours. The server room requires a special badge. The CEO’s office has a different key entirely.
Each door checks who you are before it opens.
Smart contracts work the same way. Every function is a door. Some doors should be open to everyone, like reading a token balance. Others should be locked, like withdrawing the contract’s funds or pausing the entire protocol.
Access control is the system that decides which addresses can walk through which doors.
Without it, every door is wide open. Anyone who finds the function can call it. And on a public blockchain, every function is visible to every person on the planet.
Why this matters for your project
The consequences of missing access control are not theoretical. In 2017, a flaw in the Parity Multisig wallet’s access control allowed a user to take ownership of a library contract and call selfdestruct, permanently freezing over $150 million in ETH. The function that destroyed the contract had no restriction on who could call it, and the action was likely accidental rather than a deliberate attack.
In 2022, the Wormhole bridge exploit cost $324 million because the contract failed to properly validate guardian signatures, letting an attacker forge credentials and mint tokens out of thin air. The Bancor Network hack in 2018 followed a similar pattern: attackers gained control of a wallet with elevated permissions because the privilege escalation path was not properly guarded.
These are not edge cases. The OWASP Smart Contract Security project lists improper access control as the single most critical vulnerability class, ahead of reentrancy, integer overflow, and every other exploit category. If you are building anything that holds value, access control is the first thing to get right.
How it works (the 30-second version)
The most common access control pattern in Solidity is the onlyOwner modifier. Here is what it looks like:
address public owner;
modifier onlyOwner() {
require(msg.sender == owner, "Not the owner");
_;
}
function withdraw() public onlyOwner {
payable(owner).transfer(address(this).balance);
}Three pieces work together. msg.sender is the address calling the function. require checks a condition and reverts the entire transaction if it fails. The modifier wraps that check into a reusable label you can attach to any function. The underscore (_;) marks where the function body runs, meaning the check happens first.
When someone calls withdraw(), Solidity runs the onlyOwner modifier before executing the function. If msg.sender does not match owner, the transaction reverts immediately.
No funds move. No state changes. The caller just wasted a small amount of gas.
For more complex systems, OpenZeppelin’s AccessControl contract provides role-based permissions where multiple addresses can hold different roles (admin, minter, pauser), each gating different sets of functions. But the core principle is identical: check who is calling, and revert if they do not have permission.
How Doodledapp makes this visual
In Doodledapp, the onlyOwner pattern maps directly to four connected nodes. Instead of writing the modifier syntax, you build the permission logic by connecting visual blocks on a canvas.
| Solidity concept | Doodledapp equivalent |
|---|---|
modifier onlyOwner() | Modifier node with name “onlyOwner” |
require(msg.sender == owner) | Require node with Compare connected to Msg.Sender |
msg.sender | Msg.Sender node (outputs caller address) |
function visibility | Function node’s Public toggle |
Here is how the nodes connect. You start with a Modifier node, give it the name “onlyOwner,” and connect its execution output to a Require node. The Require node needs a condition, so you connect a Compare node to its condition input.
The Compare node takes two values: on one side, a Msg.Sender node (which outputs the caller’s address), and on the other side, a reference to your owner state variable. Set the Compare operator to “Equal,” and you have a complete access check.
When you attach this modifier to a Function node, any call to that function runs the Require check first, exactly like the Solidity code above. The visual flow makes the logic explicit: you can see the permission gate, trace what it checks, and verify it is connected before you ever compile.
The Function node’s Public toggle controls external visibility. Setting a function to non-public means only other functions inside the contract can call it, which is another layer of access control that does not require a modifier at all.
Common mistakes to avoid
Forgetting access control on sensitive functions. This is the most exploited vulnerability in smart contract history. Every function that moves funds, changes ownership, pauses the contract, or modifies critical state needs an explicit permission check. If you cannot point to the Require node (or modifier) that gates a function, it is unprotected.
Using tx.origin instead of msg.sender. tx.origin returns the original external account that initiated the transaction, not the immediate caller. This makes it vulnerable to phishing attacks where a malicious contract tricks a user into calling it, then forwards the call to your contract. Always use msg.sender for access checks.
Centralizing all power in a single owner. If one address controls everything, losing that private key means losing the entire contract. For production systems, consider multi-signature wallets, timelocks, or role-based access where different addresses control different capabilities.
Leaving initialization functions unguarded. Some contracts use an initialize() function instead of a constructor (common in upgradeable proxy patterns). If that function can be called by anyone, an attacker can reinitialize the contract and seize ownership. The 88mph exploit used exactly this vector to gain admin privileges on deployed contracts.
The bottom line
Access control is not an advanced feature you add later. It is the foundation that every other piece of your contract depends on. The pattern is simple: check who is calling, compare against who is allowed, and revert if they do not match. In Doodledapp, that entire pattern is four connected nodes you can see, trace, and verify before a single line of Solidity is generated.