Path equivalence attacks using “/./” are reduced by normalising paths before access checks, resolving them to a canonical form, and applying authorisation to the normalised result. Applications should reject unsafe traversal patterns, compare against approved directories after canonicalisation, and use safe library functions rather than string matching, which can miss equivalent paths.
How path equivalence creates an access-control bypass
The main danger with /./ is that one component may treat it as a different path while the filesystem resolves it to the same location. That gap is enough to defeat allowlists, directory restrictions, and “starts with” checks if validation happens on the raw string instead of the resolved path. Canonicalisation closes that gap by making the security decision against the path the system will actually access.
Safe handling is about sequencing, not just syntax. First normalise or resolve the path, then compare it to an approved base directory, then perform the access check on that canonical result. If your application uses multiple layers, every layer that interprets the path must agree on the same normalised form, otherwise a later component can reintroduce the bypass.
String matching is especially fragile because equivalent paths can be represented in more than one way, and some helper methods only remove obvious separators without enforcing an actual canonical form. A safer design is to rely on library routines that resolve dot segments, reject unexpected traversal patterns, and return a path object that can be compared structurally rather than textually. The CWE Top 25 Guide is useful background here because path equivalence sits in the same family of common weakness patterns as poor input validation and path handling flaws.
What a secure mitigation looks like in practice
For web applications, file services, and internal tooling, the key requirement is that authorisation must be tied to the final resolved location, not to user-supplied text. That means canonicalising before the security decision, rejecting unsafe alternate encodings or traversal forms early, and ensuring the checked path stays inside the intended directory even after resolution. If the platform provides a secure join or canonical path API, use that instead of constructing checks manually.
Implementation details matter. The safest pattern is to resolve the user input against a known root, verify that the result is still beneath that root, and only then open or read the resource. If a framework or language makes it difficult to compare paths reliably, shift to allowlisting file identifiers or resource keys rather than accepting raw path fragments. This is often more robust than trying to maintain a long list of forbidden path variants.
Operationally, it helps to test the code with equivalent forms such as repeated dot segments, mixed separators, and encoded variants that normalise to the same target. If the security decision changes when the string changes but the resource does not, the control is not yet reliable. The OWASP API Security Top 10 is a useful companion when the vulnerable surface is exposed through an API, because it reinforces the need for object and function access checks on the final resource rather than on user-controlled input shape.
Where path normalisation fails and what to harden next
Path normalisation only helps if it happens before every trust decision and against the same filesystem semantics the runtime will use. If validation occurs in one layer and file access in another, equivalent paths can be reinterpreted later. Case sensitivity, symbolic links, platform-specific separators, and alternate encodings can all create a mismatch between the string you inspected and the object you actually touched.
The practical hardening point is to treat path handling as an access-control problem, not just an input-cleanup problem. If the application must accept user-controlled paths, constrain the input to a narrow expected pattern, map it to an internal identifier where possible, and log rejected variants so you can spot probing. When file access is security sensitive, review whether the surrounding service also needs tighter OS-level directory permissions so an application mistake cannot escape its intended scope.
The NIST Privacy Framework is not a file-path guide, but its emphasis on data handling boundaries is relevant when paths expose sensitive records, because the real impact is often unauthorized disclosure rather than just malformed input handling. That is why the same weakness can become more serious in systems that serve confidential documents, exports, or tenant-isolated data.
Risk and Threat Considerations
Path equivalence flaws are attractive because they let an attacker target a control gap between policy and implementation. If the security check sees one string and the filesystem acts on another, the attacker may reach data or functions that were meant to be blocked. The same weakness can also support probing for hidden directories, sensitive files, or administrative resources.
Failure mechanism: The application validates the user-supplied path before canonicalisation, or uses a brittle text comparison that does not account for equivalent representations such as /./. The filesystem then resolves the request to a different effective location, bypassing the intended boundary.
Impact: Unauthorised file disclosure, access to restricted application assets, and in some designs further abuse such as configuration tampering or chained traversal to higher-value data. Where the path controls write access, the consequence can extend beyond disclosure into integrity loss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Path checks must enforce access to the resolved resource, not user text. |
| Recommendation — Verify authorization against the canonicalized path or resource identifier. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The issue is preventing unauthorized access after path resolution. |
| SI-10 — Information Input Validation | Unsafe path forms are input-validation failures that affect security decisions. | |
| Recommendation — Enforce access decisions on the normalized target path before file access. Validate and canonicalize path input before it reaches authorization logic. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure coding practices should prevent path normalization and authorization bugs. |
| Recommendation — Build file-access logic with safe path handling and tested allowlists. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The flaw breaks access control around a protected resource path. |
| Recommendation — Bind access control to the final resolved resource location. | ||
Practitioner Guidance
What to verify: Confirm that the exact path checked by the authorisation logic is the same resolved path used by the file operation. If you cannot demonstrate that with a test case, treat the mitigation as incomplete.
Decision rule: If the application accepts user-supplied paths, prefer canonicalisation plus allowlisting of the resolved destination; if it only needs to identify a known object, replace raw paths with internal IDs or preapproved resource names.
Common mistake: Relying on blacklist strings for /./ or a few traversal variants, while leaving other equivalent encodings or platform-specific normalisation behaviours untested.
Practitioner takeaway: The control is effective only when the authorisation decision and the filesystem view are the same view, so validate the canonical path, not the user’s original text.
Related resources from NHI Mgmt Group
- What causes path equivalence: '/./' (single dot directory)?
- Path Equivalence: '/./' (Single Dot Directory)
- How should K-12 schools reduce identity risk when Active Directory is a likely attack path?
- How should security teams use attack path mapping to reduce the risk of privilege escalation in Active Directory?