I'd like to re-open for discussion this issue we discussed in ~2015: #7
In it, we decided that ResourceTiming entries that contain HTTP Basic Auth in the URL (e.g. https://username:[email protected]) should be kept in the .name (URL) field.
While I think we all agree that this is not best-practice to hard-code credentials into URLs, in the real world we are still seeing this happen in a few scenarios across the web:
- On test sites, XHR and
fetch() querying test data with credentials hard-coded in the URL
- Some
<a hrerf="https://username:[email protected]"> links with credentials hard-coded to e.g. Apache Basic-Auth protected domains or paths
In the DOM/JavaScript, URLs that contain credentials may be read by scripts in a few ways.
Let's say you navigate via a <a href="https://username:[email protected]">click</a> link:
window.location.href will not show the credentials for the page's URLdocument.URL will show the credentials for the page's URL- ResourceTiming entries in the
.name will show the credentials for any same-domain sub resources fetched (imgs, css, script, etc) and for any programmatic fetches (XHR/fetch) if on the same domain and for any programmatic fetches with credentials hard-coded
- JavaScript error stacks will show the credentials for any scripts on the same domain
From a compat POV, Chrome and Firefox report the credentials in ResourceTiming, but Safari does not.
Unfortunately this makes it relatively easily to unintentionally capture and potentially exfiltrate credentials, either by the sites themselves, or for a third-party RUM provider.
We discussed this on the 2023/01/19 W3C WebPerf call: https://docs.google.com/document/d/1PNqm7eHbtHjb8d4VQNiti3wuPk3WKLzRs7tUCXXISrA/edit#
My summary of that discussion:
- I did not hear any objections to removing credentials from ResourceTiming entries
- Three options for removing credentials:
- Remove the ResourceTiming entry entirely
- Remove just the
username or username:password from the URL <--- this seemed to be generally prefered
- Replace
username:password with a token e.g. *:* to indicate that credentials were used, but redacted
- We couldn't come up with any significant scenarios where you'd want to retain credentials in the ResourceTiming URLs
I'd like to re-open for discussion this issue we discussed in ~2015: #7
In it, we decided that ResourceTiming entries that contain HTTP Basic Auth in the URL (e.g.
https://username:[email protected]) should be kept in the.name(URL) field.While I think we all agree that this is not best-practice to hard-code credentials into URLs, in the real world we are still seeing this happen in a few scenarios across the web:
fetch()querying test data with credentials hard-coded in the URL<a hrerf="https://username:[email protected]">links with credentials hard-coded to e.g. Apache Basic-Auth protected domains or pathsIn the DOM/JavaScript, URLs that contain credentials may be read by scripts in a few ways.
Let's say you navigate via a
<a href="https://username:[email protected]">click</a>link:window.location.hrefwill not show the credentials for the page's URLdocument.URLwill show the credentials for the page's URL.namewill show the credentials for any same-domain sub resources fetched (imgs, css, script, etc) and for any programmatic fetches (XHR/fetch) if on the same domain and for any programmatic fetches with credentials hard-codedFrom a compat POV, Chrome and Firefox report the credentials in ResourceTiming, but Safari does not.
Unfortunately this makes it relatively easily to unintentionally capture and potentially exfiltrate credentials, either by the sites themselves, or for a third-party RUM provider.
We discussed this on the 2023/01/19 W3C WebPerf call: https://docs.google.com/document/d/1PNqm7eHbtHjb8d4VQNiti3wuPk3WKLzRs7tUCXXISrA/edit#
My summary of that discussion:
usernameorusername:passwordfrom the URL <--- this seemed to be generally preferedusername:passwordwith a token e.g.*:*to indicate that credentials were used, but redacted