Access control is the process of granting or denying specific requests to obtain and use information and related information processing services.
Ensure that a verified contract satisfies the following high-level requirements:
- Users and other contracts are associated with a well-defined set of roles and privileges,
- Access is granted only to privileged users and contracts.
Category “G5” lists requirements related to the access control mechanisms of the smart contracts.
| # | Description |
|---|---|
| G5.1 | Verify that the principle of the least privilege exists. Other contracts should only be able to access functions and data for which they possess specific authorization. |
| G5.2 | Verify that new contracts with access to the audited contract adhere to the principle of minimum rights by default. Contracts should have minimal or no permission until access to the new features is explicitly granted. |
| G5.3 | Verify that the creator of the contract complies with the rule of the least privilege and that their rights strictly follow the documentation. |
| G5.4 | Verify that the contract enforces the access control rules specified in a trusted contract, especially if the dApp client-side access control is present and could be bypassed. |
| G5.5 | Verify that the calls to external contracts are allowed only if necessary. |
| G5.6 | Verify that the code of modifiers is clear and simple. The logic should not contain external calls to untrusted contracts. |
| G5.7 | Verify that all user and data attributes used by access controls are kept in a trusted contract and cannot be manipulated by other contracts unless specifically authorized. |
| G5.8 | Verify that the access controls fail securely, including when a revert occurs. |
| G5.9 | Verify that if the input (function parameters) is validated, the positive validation approach (allowlisting) is used where possible. |
| G5.10 | Verify that passing privileged access to another address is two-step operation. |
| G5.11 | Verify that every role grant, revocation, and admin change emits an event, and that grants to high-impact roles are time-locked. |
| G5.12 | Verify that DEFAULT_ADMIN_ROLE (or equivalent root role) cannot be renounced unintentionally and is held by a multisig or DAO, never by an EOA in production. |
| G5.13 | Verify that privileged functions reject calls made through delegatecall when this is not the intended invocation path (e.g. by checking address(this) == __self). |
| G5.14 | Verify that integrations with EIP-7702 delegated EOAs and ERC-4337 smart accounts still resolve msg.sender to the entity the access-control logic expects. |
| G5.15 | Verify that signature-gated access uses EIP-712 typed data with a domain separator bound to chain ID and contract address. |
For more information, see also:
- OWASP Cheat Sheet: Access Control
- OpenZeppelin: Access Control
Request an audit of your project by SCSVS authors. Contact a specialist.