w3c / w3c/resource-timing

Capturing basic auth credentials in URLs, part 2

Open
#368 1 comment 0 reactions 1 assignee View on GitHub

@clelland is already working on this.

Since Jan 30, 2023.

Dominant language
Bikeshed
Stars
135
Forks
40
PR merge metrics
No merged PRs in 30d

Description

I'd like to re-open for discussion this issue we discussed in ~2015: https://github.com/w3c/resource-timing/issues/7

In it, we decided that ResourceTiming entries that contain HTTP Basic Auth in the URL (e.g. https://username:password@domain.com) 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:password@domain.com"> 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:password@domain.com">click</a> link:

  • window.location.href will not show the credentials for the page's URL
  • document.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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.