Why URLs Like /api/;/user/info Still Work: Server Parsing and RFC Rules

Introduction

The URL /api/;/user/info can be accessed normally. This behavior stems from the way web servers parse URL paths, allowances in RFC specifications, and tolerant routing matching.

URL Specification Basics

In the older RFC 2396, the semicolon ( ;) is the official delimiter for path parameters. Although the current RFC 3986 treats the semicolon as an ordinary reserved character without special semantics, many servers retain the legacy parsing logic for backward compatibility. /pathSegment;paramName=value/nextSegment For example, /user;jsessionid=abc123/info is a valid URL where jsessionid=abc123 is a path‑parameter that does not affect routing; the server strips it and matches /user/info.

How Servers Parse /api/;/user/info

The segment after /api/ contains an empty path parameter represented by a solitary semicolon. When parsed according to the old path‑parameter rules, the URL is split into the parts api, ;, user, and info. Containers such as Apache Tomcat or Jetty normalize the path by merging api with its empty parameter ;, then continue processing the remaining user/info segment. The final route that the router matches is: /api/user/info Thus the semicolon is effectively “eaten” and becomes an invisible part of the route.

Common Malformed URLs That Still Resolve

/api//user/info
/api/./user/info
/api/;/user/info
/api;;/user/info
/api;xxx/;/user/info

All of these examples are normalized by the server—removing duplicate slashes, resolving ./, discarding empty parameters, and collapsing multiple semicolons—so they ultimately map to the same intended endpoint.

Security Risks

Route bypass : Authentication filters that only match /api/user/info may miss the malformed /api/;/user/info, allowing unauthorized access.

WAF bypass : Regular‑expression rules in a Web Application Firewall that do not account for semicolons may fail to block malicious paths, while the backend still routes the request.

Potential directory‑traversal exploits : Certain malformed paths can be leveraged for further attacks, though the article only lists this as a possibility.

Defensive Measures

Normalize URL paths on the backend: strip semicolons, duplicate slashes, ./, and ../ segments.

Reject requests that contain empty path parameters ( ;) before routing.

Enforce strict, exact route matching to avoid fuzzy prefix matches.

Configure Nginx (or similar reverse proxies) to block or rewrite URLs containing illegal semicolons.

One‑sentence summary: The semicolon is a standard path‑parameter delimiter; servers automatically discard empty semicolon parameters and normalize the path, so even malformed URLs like /api/;/user/info match the intended route, but this behavior can be abused for routing and WAF bypasses.