Solidity visibility specifiers are keywords that control which contracts, functions or state variables can be accessed from inside or outside a smart contract. They include public, private, internal and external, and they shape contract interface exposure, inheritance behaviour and the attack surface for callable code.
What Solidity Visibility Specifiers Control
Solidity visibility specifiers define where a contract member can be called or read from. They are part of the contract’s access boundary, because they determine whether code is exposed externally, limited to inheriting contracts, or kept internal to the contract itself.
Why Visibility Matters in Smart Contract Design
Visibility is not just syntax, it is part of the trust model of a contract. A function marked public or external becomes part of the callable surface, while internal and private reduce exposure and can prevent accidental use of helper logic or sensitive state from outside the intended scope.
That matters because smart contract interfaces are public by default in how they are reviewed, integrated, and attacked. If a function is visible when it should not be, the contract may expose state transitions, privileged operations, or assumptions that were meant to stay encapsulated. For a broader security view of contract exposure, the Smart Contract Security Guide is the natural starting point.
How Visibility Interacts With Inheritance and State
Visibility specifiers also shape inheritance behaviour. An internal function can be reused by child contracts, while a private one cannot, which changes how logic is composed across an inheritance tree and how much of the implementation surface is inherited versus hidden.
For state variables, visibility affects whether generated getter functions exist and how much state is intentionally exposed to other contracts and off-chain readers. Even when visibility does not provide secrecy in the human sense, it still defines the official interface boundary and influences how other contracts, tooling, and users interact with the code.
Common Misuses and Security Consequences
The main security issue is not that visibility alone creates a vulnerability, but that incorrect visibility can amplify one. A function that should remain internal may become directly callable, and a state variable exposed through public access may reveal contract behaviour that an attacker can use for planning, front-running, or privilege discovery.
Conversely, over-restricting visibility can break composability, make upgrade paths harder, or force developers to duplicate logic in unsafe ways. The design challenge is to expose only what is intended as part of the contract’s public interface, and keep helper logic and sensitive control paths as narrow as possible.
Risk and Threat Considerations
Incorrect visibility can create an expanded attack surface, expose sensitive contract behaviour, or make a privileged code path callable in ways the author did not intend. In smart contracts, that often turns a design mistake into an on-chain security failure because the published interface is executable by anyone.
Failure mechanism: A function or variable is assigned broader visibility than the contract logic assumed, so external callers or descendant contracts can reach code that should have stayed encapsulated.
Impact: Attackers may trigger unintended state changes, observe implementation details that support exploitation, or chain the exposed entry point into a larger contract compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Visibility defines which callers can reach contract entry points. |
| V15 — Secure Coding and Architecture | Visibility is an architectural choice that shapes contract boundaries and inheritance behaviour. | |
| Recommendation — Review contract entry points and restrict callable functions to the narrowest intended scope. Design Solidity interfaces so helper logic and sensitive paths remain encapsulated. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Visibility should limit who can invoke code paths or observe state. |
| Recommendation — Apply least-privilege principles to exposed contract functions and inherited logic. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Overexposed contract interfaces resemble public attack surfaces that can be probed and abused. |
| Recommendation — Map externally callable contract functions to exposed attack surface and prioritize review. | ||
Practitioner Guidance
Why practitioners should care: Visibility choices are interface decisions, not cosmetic style choices. They should be reviewed alongside access control, inheritance design, and upgrade patterns, because the wrong setting can widen the callable surface of the entire contract.
Common misunderstanding: Developers sometimes treat private as a secrecy mechanism. In practice, visibility governs contract access semantics, not confidentiality in the broader security sense, so the real question is whether the function or variable belongs in the external contract interface at all.
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