Say goodbye to URLs with embedded credentials
Starting with version 59 Chrome is set on the path to stop supporting URLs with embedded credentials, like https://user:pass@host
Chrome started with blocking just the subresource requests containing credentials:
While you would not usually have those hardcoded in a page, when you open a URL likehttps://user:pass@host and that page makes subsequent requests to resources linked via relative paths, that’s when those resources will also get the user:pass@ part applied to them and banned by Chrome right there. The resulting page will look broken — missing images, broken CSS and non-working JS.
The only way know what’s going on is to look in the browser console, where the following warning message shows up:
> [Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are blocked. See https://www.chromestatus.com/feature/5669008342777856 for more details.Simply reloading the page won’t help. Opening the same page in another tab without the embedded credentials in the URL will. That’s because at this point you are already authenticated and credentials are passed encoded via the Authorization header instead of the URL.
In the near future Chrome aims to drop support for such URLs altogether.
While this may sound like a thunder from clear skies for Chrome users, it is not. The deprecation “order” comes from RFC 3986:
...
3.2.1. User Information
...
Use of the format "user:password" in the userinfo field is deprecated.
...7.5. Sensitive Information
URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies). A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public.
...
So Chrome is just following the other browsers in getting in compliance with the official RFC spec.
There are discussions like this one on StackOverflow on how to overcome this new for Chrome behavior:
BTW, here’s how other browser are handling the situation.
Firefox will ask for a simple confirmation:
Once you click confirm, the page loads up with credentials stripped out of the browser address bar. In my case the page would mostly work, but I still had issues with an AJAX login overlay being loaded as a plain JSON.
Safari makes it a major deal with a big red Possible Phishing Website warning message:
After clicking Ignore Warning, the page loads and has the same broken elements as with Chrome. Unlike Chrome though, Safari does not strip out credentials from the address bar (they are visible there in plain text). Clicking on any internal link or reloading the page results in the red warning screen.
Edge and Internet Explorer 11 behave differently.
Edge would ignore the credentials in the URL and just ask for them again in a popup:
After entering credentials, the page loads and everything works as expected.
Internet Explorer 11 just barks back that the URL is incorrect:
According to KB 834489, Internet Explorer has been doing this for over a decade at this point (since 2004)!
