Rewrites

How rewrites work

Rewrites change a request before the application processes it. They can remove an implementation detail from the public URL, map a friendly path to an internal resource, or standardise inconsistent request patterns so routing stays predictable. The core idea is transformation, not content creation, so the original request shape may differ from the target path seen by the backend.

Where rewrites sit in the request flow

Rewrites usually happen at the edge, in a reverse proxy, web server, API gateway or router, before the request reaches the origin application. That placement matters because the rewritten path can influence which handler receives the request, which policy is applied and whether downstream components even see the original URL. In multi-layer environments, the same request may be rewritten more than once.

Because rewrites act early, they are often part of request normalisation. That can be useful for clean URLs, legacy migration, tenant routing and path consolidation, but it also means that security controls must be consistent across the rewritten and original forms of the request.

Why rewrites can change security behaviour

A rewrite is not just a presentation concern. If two paths that look different to users resolve to the same backend resource, access decisions, logging, caching and allowlists can diverge unless they are designed around the final resolved target. That is why rewrites often intersect with authorization, input validation and routing policy even when they are introduced for operational convenience.

Small mistakes can create subtle mismatches, such as a public path that appears restricted but rewrites to a sensitive internal endpoint, or a rule set that sends authenticated and unauthenticated traffic to different handlers than intended. Those failures are often configuration problems rather than code defects, which makes them easy to overlook during application testing.

Common operational patterns and edge cases

Rewrites are used for canonicalisation, legacy compatibility, A/B routing, tenant separation and reverse-proxy abstraction. They can also support migrations by preserving old links while the backend structure changes. The risk is that each additional rule increases complexity, and complexity makes it harder to reason about the exact request path that the application receives.

Edge cases matter most when rewrites interact with encoded characters, trailing slashes, case sensitivity, query strings or chained proxy layers. If different components apply different normalisation rules, the same request may be interpreted in more than one way, which can produce broken links, unexpected handler selection or inconsistent security enforcement.

Risk and Threat Considerations

Rewrites create security risk when the public path and the backend path do not receive the same policy treatment. That mismatch can lead to broken access control, request smuggling between layers, cache confusion or exposure of internal resources that were meant to stay hidden.

Failure mechanism: An attacker or misconfigured client targets a path that is rewritten into a more privileged or differently handled backend route, and the security decision is made on the wrong form of the request.

Impact: Sensitive endpoints may become reachable, logs may not reflect the effective destination, and incident investigation becomes harder because the original request does not clearly show what the backend actually processed.

Practitioner Guidance

What to watch for: Treat rewrites as part of the security boundary, not just a routing convenience. The most important question is whether the rewritten destination inherits the same authentication, authorization, rate limiting and logging expectations as the original request path.

Governance implication: Keep rewrite rules explicit, versioned and reviewed alongside routing and access-control changes. If multiple layers rewrite requests, document the final canonical form so operators, developers and security reviewers can reason about the same target path.

Related resources from NHI Mgmt Group

• Why do route rewrites create authorization risk in admin workflows?
• Who is accountable when an AI assistant rewrites its own traffic path?
• What breaks when a gateway rewrites real-time speech traffic into a generic audio API shape?
• How should security teams prevent cache deception when framework rewrites can change the effective request path after caching decisions are made?