Path normalization standardizes HTTP request paths before they reach your backend services. Without normalization, attackers can craft equivalent paths that bypass authorization policies. Service Mesh (ASM) provides four normalization policies with different levels of strictness.
Why path normalization matters
ASM authorization policies match request paths to allow or deny traffic to workloads in a Kubernetes cluster. If a request path is not normalized, an attacker can bypass these policies by using an equivalent but differently formatted path.
Example: authorization policy bypass
Suppose an authorization policy rejects requests to /data/secret. The following paths bypass this policy because they do not exactly match /data/secret:
| Request path | Why it bypasses the policy |
|---|---|
/data//secret | Contains a double slash |
/data/../data/secret | Contains a relative path segment |
/data%2Fsecret | Uses a percent-encoded slash |
Most backend applications treat all three paths as equivalent to /data/secret. This mismatch between proxy enforcement and backend interpretation creates a security gap.
Path normalization closes this gap. Sidecar proxies normalize incoming request paths before evaluating authorization policies, so the proxy and the backend interpret paths consistently.
Do you need to change the policy?
Not always. Consider the following scenarios:
No path-based authorization policies. No action needed. Path normalization only affects how authorization policies evaluate request paths.
Path-based authorization policies, but unsure which policy to pick. Use DECODE_AND_MERGE_SLASHES, the strictest option. It provides the broadest protection against bypass attempts.
Specific path handling requirements. Choose the policy that matches how your application normalizes paths internally. See the decision table.
Available policies
ASM provides four path normalization policies. Each builds on the previous one with additional normalization steps.
| Policy | What it does | Example |
|---|---|---|
| NONE | No normalization. Paths are forwarded as-is. | ../%2Fa../b stays ../%2Fa../b |
| BASE | Normalizes paths per RFC 3986. Resolves relative segments. | /a/../b becomes /b |
| MERGE_SLASHES | Applies BASE normalization, then merges consecutive slashes into a single slash. | /a//b becomes /a/b |
| DECODE_AND_MERGE_SLASHES | Applies MERGE_SLASHES normalization, then UTF-8 decodes percent-encoded characters (%2F, %21, %5C) into / and \, and merges any resulting consecutive slashes. | /a%2Fb becomes /a/b |
How to choose
| Your application... | Choose |
|---|---|
| Does not normalize paths and relies on the proxy to do it | DECODE_AND_MERGE_SLASHES (recommended) |
| Normalizes paths per RFC 3986 but does not merge slashes | BASE |
| Normalizes paths per RFC 3986 and merges slashes but does not decode percent-encoded characters | MERGE_SLASHES |
| Normalizes paths per RFC 3986, merges slashes, and decodes percent-encoded characters | DECODE_AND_MERGE_SLASHES |
| Handles paths in a non-standard way that is incompatible with RFC 3986 | NONE |
If unsure, start with DECODE_AND_MERGE_SLASHES. Test your authorization policies with both normalized and non-normalized paths to verify the expected behavior.
Configure the policy
Prerequisites
Before you begin, make sure that you have:
An ASM instance with sidecar proxies deployed
Permissions to manage the ASM instance
Procedure
Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance.
On the Base Information page, find Path Normalization Policy in the Config Info section and click Edit on the right side.
In the dialog box that appears, select a path normalization policy and click OK. The new policy takes effect on all sidecar proxies in the ASM instance. Sidecar proxies normalize HTTP request paths based on the selected policy before evaluating authorization policies.