Treat every path fragment from the user as untrusted and validate it before any file access occurs. Normalize the path, decode encoded characters, reject traversal tokens such as ../, and allow only a narrow set of expected filenames or extensions. The safest pattern is to compare the final resolved path against an approved base directory before reading or writing files.
Why file-path construction becomes dangerous in .NET applications
path traversal appears when an application treats user-controlled text as part of a filesystem location. In .NET, that can happen through download handlers, document viewers, export routines, upload processing, tenant-specific storage, and any feature that joins a base directory with a user-supplied filename or folder name. The real issue is not just invalid input, but the possibility that the final resolved path escapes the intended directory and exposes data or overwrites files.
Teams often miss the fact that normalisation alone is not a guarantee of safety. Encoded separators, mixed slash conventions, alternate data representations, and platform-specific path rules can all turn apparently harmless input into an unsafe location. A secure design therefore has to decide what a valid path fragment looks like before any file operation is attempted, not after the path has already been concatenated. In practice, many teams discover the weakness only after an unexpected read or overwrite path has already been exercised.
How safe path handling works in practice
The safest pattern is to avoid letting user input define structure at all. If the application only needs to select a known file type, use an allowlist of expected names, identifiers, or extensions and map those values to server-side paths. If the application genuinely needs to accept a filename, treat that filename as data, not as a path segment, and resolve it against a fixed base directory before any file system access.
That validation should happen after decoding and normalisation, because path traversal often relies on representation tricks rather than obvious literal ../ tokens. A robust implementation checks the final resolved path and confirms that it still sits inside the approved directory tree. This comparison must be done on the fully resolved result, not on the raw input string, because string checks can be bypassed by separators, relative segments, or platform-specific quirks.
For .NET teams, the practical control points usually look like this:
- Use a fixed root folder and never let the user choose the root.
- Allow only a narrow set of filename patterns, extensions, or identifiers.
- Normalize and decode input before validation.
- Resolve the final path and verify that it remains under the approved base directory.
- Reject inputs that contain path separators, traversal tokens, device paths, or unexpected absolute-path forms.
Where teams also handle uploads or generated artifacts, the safest design is to separate the user-visible name from the stored filename. That reduces ambiguity and makes it easier to enforce consistent storage policy, logging, and cleanup. When the business requirement is more complex than a simple filename lookup, the design should move toward a lookup key or object identifier rather than free-form path construction. For identity-bound storage and automation scenarios, path safety often overlaps with how trusted service accounts, agents, or background jobs are authorised to reach file locations, so file access should remain tightly scoped to the minimum directory set needed.
This guidance breaks down when an application must preserve arbitrary user-provided folder structures or act as a general file browser, because then the input is no longer a simple filename problem and the trust boundary is much broader.
Where edge cases, legacy code, and platform rules change the answer
Tighter path validation often increases friction for users and developers, requiring organisations to balance flexibility against predictable access control. That tradeoff matters most in legacy systems, cross-platform .NET deployments, and products that must support multiple storage conventions without opening escape routes.
Some edge cases deserve special care. Windows-style device paths, alternate separators, mixed encodings, and case-insensitive comparisons can all produce surprises if the validation logic is too simplistic. A path that looks safe in one representation may resolve differently after framework methods process it, so teams should verify the resolved result rather than trusting the input form. There is also a real difference between rejecting traversal and securely mapping known safe values: the first reduces abuse, while the second often produces more reliable long-term design.
External guidance on secure identity and access boundaries can help teams think about delegated access to filesystem-like resources, but the core defensive decision here remains local to the application: never let untrusted input define the boundary in the first place.
For broader trust-boundary thinking, the OWASP Non-Human Identity Top 10 is useful when file access is performed by service accounts, automation, or agents that carry privileged filesystem rights.
Risk and Threat Considerations
Path traversal creates confidentiality, integrity, and sometimes availability risk because it can let an attacker read sensitive files, overwrite application data, or target configuration and credential material that should never be reachable through a user-facing feature. The danger increases when file access is performed by a privileged application account with broader directory access than the feature truly needs.
Failure mechanism: The weakness materialises when the application constructs a path from untrusted input and then trusts string-based checks instead of validating the resolved filesystem target. Attackers exploit traversal tokens, encoded separators, or path normalisation differences to escape the intended directory boundary and reach files outside the allowed scope.
Impact: Successful exploitation can expose source code, secrets, configuration files, logs, or tenant data, and it can also corrupt files that the application depends on for normal operation. In environments where the file path is tied to automated jobs or agentic workflows, the same flaw can expand the blast radius of a single request 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.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 3 — Data Protection | Path traversal can expose sensitive files and data beyond the intended directory. |
| CIS 5 — Account Management | Privileged service accounts amplify the impact of unsafe file-path access. | |
| Recommendation — Restrict file access paths and protect sensitive data stores from unintended disclosure. Limit application account permissions to the minimum directories required. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | User input must not expand file-system access beyond approved boundaries. |
| PR.DS-5 — Data at Rest Protected | Unsafe path handling can expose or overwrite stored files and secrets. | |
| Recommendation — Enforce least-privilege access so file operations stay within authorized scope. Protect stored files so path abuse cannot expose or alter protected data. | ||
| MITRE ATT&CK | T1083 — File and Directory Discovery | Traversal abuse often targets the discovery and retrieval of filesystem content. |
| Recommendation — Monitor for filesystem access patterns that indicate probing of restricted directories. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Filesystem traversal can reach secrets, tokens, and configuration used by services or agents. |
| Recommendation — Keep secrets outside user-reachable paths and separate storage from request data. | ||
Practitioner Guidance
What to prioritise: Treat the resolved-path check as the enforcement point, not the string that arrived from the request. If the application cannot prove that the final location stays inside an approved directory, it should fail closed.
What to verify: Confirm that validation happens after decoding and normalisation, and that no alternate input path bypasses the same check through a helper method, upload pipeline, or legacy code path. Teams should also verify that the process account cannot write outside the intended storage root even if validation fails elsewhere.
Common mistake: Relying on simple substring checks or blocking only ../ without validating the final resolved path. That approach looks effective in testing but tends to fail when encodings, platform path rules, or nested joins are involved.
Practitioner takeaway: The safest design is not “sanitise harder,” but “constrain the destination so hard that untrusted input cannot move it.”
Related resources from NHI Mgmt Group
- How should Rails teams prevent path traversal when building file paths from user input?
- How should security teams prevent path traversal issues when repository names are used to build filesystem paths?
- Why does using user input in file path generation increase the risk of path traversal?
- Why does a file download endpoint create path traversal risk when it accepts user-controlled input?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
