Proposal: Ignore Strict-Transport-Security headers for Localhost responses

218 views
Skip to first unread message

Eric Lawrence

unread,
Oct 18, 2024, 2:39:48 PMOct 18
to blink-dev, est...@chromium.org
CL: https://chromium-review.googlesource.com/c/chromium/src/+/5923046?tab=comments

Today, if a https://localhost:* response sets Strict-Transport-Security, HTTPS upgrades will be applied to all subsequent http://localhost requests, regardless of port. 

Localhost is inherently a secure context, and Strict-Transport-Security response headers received on https://localhost responses can cause problems because they are not isolated by port. This leads to compatibility problems for end-users who use software packages that commonly spin up localhost webservers for ephemeral reasons (e.g. communication of an auth token from a web login to a local software package).

This is also a source of friction for web developers who test their applications locally for the same reason.

I propose we resolve this problem by matching Firefox's behavior and ignoring HSTS headers on responses returned from localhost URLs.

As requested, I've proposed an errata for RFC6797 to add the following to section 8.1.1:

If the substring matching the host production from the Request-URI (of the message to which the host responded) syntactically matches the string "localhost" or ends with ".localhost", then the UA MAY choose not to note this host as a Known HSTS host.

Mike Taylor

unread,
Oct 18, 2024, 7:24:37 PMOct 18
to Eric Lawrence, est...@chromium.org, blink-dev

Should this be an Intent to Ship?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/138764fe-efad-406e-b3b0-3a1a600bc8d9n%40chromium.org.

Alex Russell

unread,
Oct 18, 2024, 11:54:10 PMOct 18
to Mike Taylor, Eric Lawrence, Emily Stark, blink-dev
It's a good proposal and if it is reformulated as an I2S, I'll approve.

Erik: lmk if i can help with paperwork there.

Reply all
Reply to author
Forward
0 new messages