2026-09-19 · 6 min read · Rahul Chitturi
- url
- security
- parsing
A URL such as https://trusted.example@other.example/ displays a trusted-looking name before the at-sign, but the network host is other.example. The earlier text is user information, not the destination hostname.
String checks that search for an allowed domain can therefore approve the wrong authority. Percent encoding, Unicode, brackets, ports, redirects, and parser disagreements make ad hoc fixes unreliable.
Parse once with one URL model
Use the runtime's standards-aware URL parser, require an allowed scheme, reject credentials unless the product explicitly supports them, and validate the parsed hostname and effective port. Apply allowlists to canonical parsed components rather than the original string.
- Reject malformed or ambiguous authority syntax.
- Treat username and password as sensitive input.
- Resolve and validate every redirect destination.
- Keep browser, server, proxy, and logging parsers aligned.
Do not leak credentials through diagnostics
HTTP clients vary in whether they reject URL credentials, convert them into an Authorization header, or preserve them across redirects. Make this behavior explicit and never forward credentials to a new authority.
Redact user information before logging, analytics, error reporting, or UI display. A normalized URL that retains a password is still a secret even if the destination is safe.
Test hostile-looking authorities
Use Flashman's URL tool with synthetic hosts, diff for parser outputs, Base64 for disposable Basic-auth fixtures, and JSON formatter for sanitized allowlist records.
Test empty and populated userinfo, multiple at-signs, percent-encoded delimiters, Unicode hosts, IPv6 literals, explicit ports, backslashes, fragments, redirects, proxy rewriting, credential redaction, private addresses, and each deployed URL parser.