A file or directory setting that allows any local user to read its contents. For configuration files, that means secrets, paths, or internal settings can be exposed without exploiting the application itself. Security teams should treat these permissions as a serious misconfiguration whenever sensitive values may be stored on disk.
Expanded Definition
World-readable permissions describe a filesystem state where any local account can read a file or directory, even if it should only be available to a service account, administrator, or deployment process. In security operations, the risk is not the permission bit by itself but the combination of broad read access and sensitive material stored on disk, such as configuration values, tokens, connection strings, API keys, certificates, or internal endpoints.
This misconfiguration is especially important in environments that rely on automation, because secrets are often written to config files, mount points, logs, or temporary paths during build and runtime. The problem is sometimes confused with ordinary file sharing or developer convenience, but world-readable access removes a basic trust boundary inside the host. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need to protect system and information integrity through access restriction and configuration control.
The most common misapplication is leaving application configuration world-readable on shared servers or containers, which occurs when teams assume local access is harmless because the file is not exposed over the network.
Examples and Use Cases
Implementing restrictive file permissions rigorously often introduces operational friction, requiring teams to balance service availability and deployment simplicity against the need to prevent unintended local disclosure.
- A Linux web application stores database credentials in a config file with mode 0644, allowing any local user to read the database path and password.
- A container image bakes an environment file into the filesystem with permissive permissions, exposing internal service names and bearer tokens to other processes on the node.
- A build artifact directory contains deployment scripts and connection strings that remain readable after release, giving low-privilege users insight into production infrastructure.
- An NHI workload writes an API key or certificate to disk and fails to restrict the file to the service account, creating a direct credential exposure path. The OWASP Non-Human Identity Top 10 is relevant when this file belongs to an automated identity rather than a person.
- A shared bastion host allows analysts to inspect a directory containing logs and runtime metadata that were never meant for general local visibility, revealing internal architecture details that support lateral movement.
Why It Matters for Security Teams
World-readable permissions turn a single host-level mistake into a disclosure issue that can accelerate credential theft, service impersonation, and privilege escalation. For security teams, the concern is broader than confidentiality alone: once internal secrets are readable by any local user, incident containment becomes harder because attackers often start with low privilege and move laterally by harvesting files that should never have been exposed.
This matters directly to identity and NHI governance because service accounts, automation tokens, and agent credentials are frequently persisted on disk during provisioning, runtime, or troubleshooting. If those artifacts are world-readable, an otherwise contained workload can become the source of an enterprise-wide identity compromise. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support the broader expectation that access to information assets should be limited to authorised subjects and that configuration states should be monitored and corrected.
Organisations typically encounter the business impact only after a post-incident review discovers that a low-privilege account could read the file that exposed the credentials, at which point world-readable permissions become operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Restricts access to information and resources to authorised users and processes. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege control applies when local read access exceeds business need. |
| OWASP Non-Human Identity Top 10 | NHI guidance highlights credential exposure risks when secrets are stored with weak file permissions. | |
| NIST SP 800-63 | Credential handling guidance is relevant when readable files expose authenticators or tokens. |
Enforce least privilege on files and directories that may contain sensitive configuration or secrets.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
