fix: reject credentialed URLs for IPv6, punycode, and text fragments

[cursor]

Bug

The full url-http API intentionally rejects credentialed HTTP(S) URLs (e.g. https://admin:admin@host), but that check could be bypassed for IPv6, punycode, and text-fragment URLs.

Impact

Callers that rely on url-http to reject userinfo-bearing URLs could accept phishing / host-confusion inputs such as:

• https://trusted.example@example.com/#:~:text=x
• https://trusted.example@xn--80a0aaa.com/
• http://trusted.example@[::1]/

These previously returned the full href (including credentials) instead of false.

Root cause

For those URL shapes, matching runs with exact: false. url-regex-safe({ auth: false }) can then match a substring after @ while url-http still returns the original href.

Fix

Reject URLs with a non-empty username or password immediately after WHATWG parsing, before the regex check.

Validation

• Added regression cases covering text-fragment, punycode, and IPv6 credentialed URLs
• npm test passes (100% coverage)

  

---

Note

Low Risk
Small, security-hardening change in URL validation with targeted tests; no broader API or dependency changes.

Overview
Closes a bypass where credentialed http(s) URLs could still validate when IPv6, punycode, or text-fragment handling ran url-regex-safe in non-exact mode and matched past the @.

After parsing with URL, the validator now returns false if username or password is set, before any regex logic—so inputs like https://trusted.example@example.com/#:~:text=x no longer return the full href.

Regression tests were added for text-fragment, punycode, and IPv6 credentialed cases in the full (non-lightweight) test suite.

^{Reviewed by Cursor Bugbot for commit ac22920. Bugbot is set up for automated code reviews on this repo. Configure here.}