Open files with protections that prevent following attacker-controlled links, and verify the final target before reading or writing. Use safe temporary file patterns, restrict writable directories, and avoid trusting names in locations an attacker can modify. Monitor for unexpected symlinks or junctions in sensitive paths and clean them up quickly.
How to stop link following from turning into file overwrite
Link following becomes dangerous when a program opens or writes a path that an attacker can redirect through a symbolic link, junction, or similar filesystem trick. The core mitigation is to make the final target deterministic: refuse unexpected link traversal, open files with safe flags, and confirm the resolved destination before any destructive read or write occurs.
Safe file handling matters most wherever the application accepts filenames in shared or attacker-influenced locations. Temporary directories, upload paths, cache folders, spool areas, and writable working directories are common failure points because the attacker can often replace a benign-looking path with a link after validation but before use.
Which filesystem patterns are safer?
Use file creation patterns that avoid name reuse and reduce race windows. Prefer exclusive creation, secure temporary file APIs, and directory permissions that keep untrusted users out of the parent path. If the application must operate in a writable tree, make the parent directory itself trustworthy, not just the file name under it. For a broader view of the weakness patterns that show up in path handling, the CWE Top 25 Guide is a useful map of common root causes.
When the path comes from outside the trust boundary, treat links and reparse points as part of the input, not as a transparent filesystem detail. That means checking whether the object is a link before open, avoiding follow-on operations that inherit attacker-chosen destinations, and using file descriptors or handles that bind to the object you actually intended to access.
What operational checks should you add?
Build verification into the workflow instead of trusting the first path check. Validate ownership, permissions, file type, and resolved target immediately before the action that matters, because earlier checks can be invalidated by a race. Where possible, work with directory handles, open-by-handle semantics, or equivalent APIs that close the time-of-check to time-of-use gap.
Monitoring also belongs in the control set. Unexpected symlinks, hard links, and junctions in sensitive paths are often a sign of tampering, misconfiguration, or a failed cleanup step. Alert on them, remove them quickly, and investigate whether any privileged process has already used the redirected path. For teams aligning operational hardening to prescriptive controls, NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support the broader discipline of secure configuration, access control, and monitoring.
Risk and Threat Considerations
Link following is risky because it lets an attacker redirect a trusted operation onto an untrusted target. The failure mode is usually a race or path substitution issue, where the application validates one object and then acts on another, often with elevated privileges or in a sensitive directory.
Failure mechanism: An attacker places or swaps a link in a writable location, then relies on the application to follow it during open, read, write, or delete operations. If the program does not verify the final object at the moment of use, the operation can escape the intended boundary and affect attacker-chosen content.
Impact: The result can be overwrite, disclosure, deletion, privilege abuse, or tampering with configuration and runtime files. In privileged services, the blast radius can extend beyond a single file to persistent system compromise or unauthorized changes in high-value locations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Link following becomes dangerous when privileged processes can reach attacker-chosen files. |
| SI-2 — Flaw Remediation | Secure file-handling weaknesses often require prompt remediation and cleanup of unsafe objects. | |
| CM-6 — Configuration Settings | Writable directories and link behavior depend on hardened filesystem configuration. | |
| Recommendation — Restrict file and directory access so privileged processes cannot act on attacker-writable paths. Patch or correct file-handling flaws and remove unsafe link objects quickly. Harden directory permissions and file creation settings to prevent unsafe link traversal. | ||
Practitioner Guidance
What to verify: Confirm that the code uses link-safe file APIs and that the final object identity is checked immediately before the sensitive action. A static code review is not enough if the runtime path can still be swapped underneath you.
Common mistake: Treating path sanitisation as equivalent to link safety. A clean-looking path can still resolve through a link, so the control has to be about the resolved object and the directory trust boundary, not just the string.
Practitioner takeaway: The safest pattern is to remove ambiguity from file selection, because once an attacker can influence the object a privileged process actually touches, path validation alone is no longer a reliable defence.