Path canonicalisation is the process of converting a request path into one standard form before routing or policy checks occur. If different layers normalize casing, slashes, or encodings differently, attackers can exploit that inconsistency to evade access controls or reach protected content.
Expanded Definition
Path canonicalisation is the control point where an application, gateway, or policy engine reduces a request path to one normal form before making an allow or deny decision. In NHI environments, this matters because agents, service accounts, and automation often traverse multiple layers, each with its own parsing rules. If a reverse proxy, API gateway, and backend service do not agree on whether /%2e%2e/, duplicated slashes, mixed case, or dot segments represent the same resource, an attacker can craft paths that pass one check but reach another target. Guidance varies across vendors on where canonicalisation should occur, but the security principle is consistent: normalise once, early, and consistently. NIST’s NIST Cybersecurity Framework 2.0 supports this kind of defensive consistency through stronger access control and secure processing expectations.
The most common misapplication is normalising only at the application layer, which occurs when proxies or upstream filters make routing decisions on a different path representation.
Examples and Use Cases
Implementing path canonicalisation rigorously often introduces compatibility and performance constraints, requiring organisations to weigh safer routing decisions against the risk of breaking legitimate edge-case requests.
- An API gateway rejects encoded traversal attempts before they reach a backend that would otherwise decode the path differently.
- A service account calling internal admin endpoints is blocked because the canonical path no longer matches a hidden or deprecated route.
- A file-serving endpoint normalises repeated slashes and dot segments so an attacker cannot use alternate encodings to escape a restricted directory.
- A CI/CD control plane applies the same canonical form across all layers, reducing the chance that an automation token can reach unintended endpoints, a pattern seen in incidents such as the SpotBugs Token GitHub Supply Chain Attack.
- A developer portal enforces consistent path parsing for documentation, webhook, and callback routes, aligning with the identity hygiene lessons highlighted in the GitHub Personal Account Breach.
For implementation detail, teams often compare their routing rules with OWASP path traversal guidance, then verify that the same canonical path is evaluated by every enforcement point.
Why It Matters in NHI Security
Path canonicalisation becomes an NHI security issue when machine identities are trusted to reach internal tooling, secrets endpoints, or automation APIs. A malformed path can bypass intended policy checks, which may expose tokens, config data, or privileged workflow functions to a service account that should not have access. That risk is amplified in environments where NHIs are already overexposed; NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. When path handling is inconsistent, the problem is not just technical correctness but governance failure: access reviews, allowlists, and service-to-service boundaries no longer mean what operators think they mean. Canonicalisation also supports Zero Trust because every request must be evaluated against the same resource identity before trust is granted. The security value is easiest to see after abuse has already occurred, when logs show a supposedly blocked route was still reachable through an alternate encoding and path controls suddenly become operationally unavoidable to fix.
That is why NHI governance should treat routing normalization as part of access control design, not as a minor web framework detail. The same discipline that prevents secret sprawl and privilege creep must also ensure that one request path means one resource across every enforcement layer.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Path inconsistency can let NHI access checks be bypassed before authorization. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on consistent resource identification across layers. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires all traffic to be evaluated consistently at enforcement points. |
| OWASP Agentic AI Top 10 | A1 | Agentic tools can misuse alternate paths to reach unintended endpoints. |
| NIST AI RMF | MAP | Path normalization is a system context risk that should be identified and governed. |
Treat canonicalisation as part of boundary protection so every request is checked against the same resource.
Related resources from NHI Mgmt Group
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- How should security teams prevent hardcoded secrets from becoming a breach path?
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- How should organisations respond when a privileged SSH certificate path is flawed?
