You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.hrefwill not show the credentials for the page's URL
document.URLwill show the credentials for the page's URL
ResourceTiming entries in the .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-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.
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.href
will not show the credentials for the page's URLdocument.URL
will show the credentials for the page's URL.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-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:
username
orusername:password
from the URL <--- this seemed to be generally preferedusername:password
with a token e.g.*:*
to indicate that credentials were used, but redactedThe text was updated successfully, but these errors were encountered: