Path sanitisation is the process of validating and normalising a file or directory path before it is used by software. It removes or rejects dangerous elements such as traversal sequences, alternate separators, and unexpected encodings so the application uses the intended location rather than an attacker-controlled one.
What path sanitization does
Path sanitization is a defensive input-handling step that makes a file or directory path safe to use before software acts on it. It validates what the application should accept, normalizes equivalent forms, and rejects or removes path tricks that would make the program resolve a different location than intended.
That matters because many path attacks do not need a broken file system, only a parser that trusts the wrong string form. A path may look harmless in one representation yet resolve elsewhere after decoding, separator handling, or canonicalization.
Why path normalization matters
Normalization reduces ambiguity. Different operating systems, file APIs, and language runtimes may treat separators, drive roots, relative segments, Unicode forms, or encoded bytes differently. If an application compares paths before normalizing them, it can make the wrong trust decision.
The common failure is not the path itself, but a mismatch between how the application interprets the string and how the underlying platform resolves it. Sanitization closes that gap by forcing the application to operate on a predictable, intended form.
What dangerous path input looks like
Attackers try to escape a permitted directory, target sensitive files, or steer the program toward another resource. Typical patterns include traversal sequences such as .., mixed or alternate separators, percent-encoding, double-encoding, unexpected prefixes, and platform-specific quirks that collapse into a valid path only after processing.
Path sanitization is most effective when paired with allowlists and an explicit base directory. The application should decide which locations are legitimate, then verify the final resolved path still sits inside that boundary rather than relying on string matching alone.
How to think about secure path handling
Good path handling treats the user-supplied string as untrusted until it has been normalized, resolved, and checked against policy. In practice, that means the safe path is the one the runtime actually opens, not the one the user typed.
For file upload, file read, archive extraction, and template loading features, the safest design is to minimize path interpretation altogether. When path-based flexibility is unavoidable, the application must account for platform differences and reject ambiguous input early.
Risk and Threat Considerations
Path sanitization failures can lead to arbitrary file read, file overwrite, configuration tampering, or code execution when the resolved path escapes the intended boundary. The same weakness can also expose secrets or application data if the program accesses files based on user-controlled input.
Failure mechanism: The application validates only the visible string, but the file system resolves a different location after normalization, decoding, or separator conversion.
Impact: An attacker may reach sensitive files, alter trusted content, or pivot from a simple file access flaw into broader system compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | Path sanitization protects file handling paths from traversal and unsafe resolution. |
| V15 — Secure Coding and Architecture | Path handling must be designed so resolution and authorization are checked consistently in code. | |
| Recommendation — Validate and canonicalize file paths before access, then enforce directory boundaries on the resolved path. Design file access flows so canonicalization and authorization occur before any file operation. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure path handling is a core application security safeguard against input-driven file access flaws. |
| Recommendation — Review path-processing code for traversal, normalization bugs, and unsafe file access patterns. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Path sanitization is a specific form of validating untrusted input before software uses it. |
| Recommendation — Apply input validation to file paths and reject values that resolve outside the authorized location. | ||
Practitioner Guidance
Common misunderstanding: Replacing .. is not enough. Sanitization has to be defined around the resolved path, the platform rules, and the exact directory boundary the application intends to protect.
What to watch for: Any feature that accepts a path, filename, archive member name, or import location deserves the same scrutiny, especially when the path is later joined, decoded, unpacked, or normalized by multiple layers of code.
Related resources from NHI Mgmt Group
- What breaks when an upload path is taken from an HTTP header without sanitization?
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- What is the difference between input sanitization and blast-radius control?
- How should security teams prevent hardcoded secrets from becoming a breach path?
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org