- From: Jerry Martinez <notifications@github.com>
- Date: Tue, 26 May 2026 00:12:56 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/465/c4541494148@github.com>
jmwebservices left a comment (whatwg/fetch#465) I agree that embedding credentials in a URL is not a secure mechanism when the intent is to protect sensitive resources. However, there are still legitimate operational use cases for this behavior that do not rely on it as a security boundary. For years, we have battled anti-phishing systems falsely classifying our staging environments as malicious or deceptive. Since staging environments are intentionally near-identical to production websites, they are frequently flagged despite being legitimate internal review systems. When Chrome presents a “Dangerous Website” warning for these staging URLs, our clients’ ability to review and approve website changes is significantly hindered. Our latest mitigation strategy was to place staging environments behind HTTP Basic Authentication. Because these staging links are often shared internally among client stakeholders, embedding the username in the URL proved to be the least disruptive workflow and has worked reliably for months. The issue we encountered appears specifically related to relative links to PDF resources. For example, when a page URL contains embedded credentials and includes a relative PDF link such as `/ABC.pdf`, Chrome appears to propagate the credential portion of the parent URL into the PDF request, causing the PDF viewer/navigation flow to fail. More broadly, I would encourage browser vendors to take a conservative approach when disabling or altering longstanding internet capabilities. Even when a feature is considered outdated or discouraged, there are often real-world operational workflows that still depend on it in controlled environments. Abrupt behavioral changes can unintentionally break legitimate use cases that are unrelated to the original security concerns the restriction was intended to address. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/465#issuecomment-4541494148 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/465/c4541494148@github.com>
Received on Tuesday, 26 May 2026 07:13:00 UTC