A Solidity require statement is a runtime check that stops execution when a condition is false. In smart contracts, it is used to validate inputs, permissions or state before proceeding, and it reverts the transaction when the check fails, helping prevent invalid or unauthorised contract actions.
What the require statement does in Solidity
A require statement is a runtime guard: it checks a condition before a function continues, and if the condition is false the transaction reverts. In smart contracts, that makes it a core control for rejecting invalid state transitions early.
Because Solidity code is immutable once deployed, these checks are part of the contract’s trust boundary. They help ensure that only valid inputs, permitted callers, and acceptable state combinations can move the contract forward.
Where require fits in contract logic
Developers usually place require near the start of a function to enforce preconditions. Common uses include validating arguments, confirming balances or ownership, and ensuring the contract is in the right phase for the action being requested.
This is different from business logic that calculates an outcome after a check passes. A require statement does not prove the contract is correct by itself, but it narrows execution to the cases the code is designed to handle.
When the condition fails, the revert prevents downstream writes and side effects. That matters in blockchain systems because failed assumptions can otherwise lead to incorrect transfers, broken invariants, or state that is expensive or impossible to unwind manually.
Why require matters for smart contract security
require is one of the simplest forms of defensive coding in Solidity, but it is also one of the most important. It supports input validation, access control checks, and state gating, all of which reduce the chance that an external caller can drive the contract into an unsafe path.
It is also a visibility mechanism for reviewers. A contract with clear precondition checks is easier to audit than one that implicitly assumes callers behave correctly. That is why security reviewers often read require statements as evidence of the assumptions the contract depends on.
Used well, require helps protect against accidental misuse and obvious abuse. Used poorly, it can create a false sense of safety if the condition is incomplete, checks the wrong variable, or is placed too late to stop harmful effects.
Common failure patterns and design limits
The main risk is not the statement itself, but weak or incomplete conditions. A guard that checks the wrong actor, the wrong state variable, or only part of a rule can still allow an unauthorized or invalid transaction to proceed.
Smart Contract Security Guide is useful background because it places require alongside broader Solidity security concerns such as access control bugs, reentrancy, and invariant failure.
Another limit is that a revert only stops the current call path. It does not correct faulty economic design, insecure external dependencies, or broken assumptions about token behavior, oracle data, or cross-contract interactions. In other words, require is a gate, not a substitute for sound contract architecture.
Developers also need to be careful about user experience and diagnosability. Clear revert reasons can make failures easier to understand, but the underlying rule still needs to be correct and complete.
Risk and Threat Considerations
In Solidity, weak or missing require checks can turn a contract into an authorization bypass or state-integrity problem. If a caller can skip a precondition, they may trigger value movement, privileged actions, or state transitions that the contract was meant to block.
Failure mechanism: An attacker or mistaken integration exploits an incomplete guard, a late check, or a logic error in the condition, then drives the contract through a path that should have been rejected before any sensitive effect occurred.
Impact: The result can be unauthorized execution, corrupted contract state, failed invariants, or loss of funds or control, especially when the missing check protects ownership, role-based actions, balance-sensitive operations, or external calls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Require statements enforce who may perform a contract action. |
| V2 — Validation and Business Logic | Require statements validate inputs and state before business logic continues. | |
| Recommendation — Map each require check to the authorization rule it must enforce and verify the rule blocks every unauthorized path. Verify that every require condition matches the contract’s intended input and state rules. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Require checks help restrict contract actions to the minimum permitted cases. |
| Recommendation — Use least-privilege logic to limit contract operations to only the callers and states that truly need them. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Missing or weak require checks can let callers invoke functions they should not reach. |
| Recommendation — Test contract functions for function-level authorization gaps before deployment and after changes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure software practices require defensive checks in application code, including smart contracts. |
| Recommendation — Review contract code for defensive precondition checks during secure development and testing. | ||
Practitioner Guidance
What to watch for: Treat each require as an explicit security assumption and review whether it fully expresses the rule the contract is trying to enforce. The useful question is not whether a check exists, but whether it blocks every invalid path before any consequential state change.
Practitioner note: In security reviews, the strongest require statements are the ones that are both early and specific, because they make the contract’s intended invariants obvious to auditors and harder for attackers to bypass.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org