Closed Bug 1412107 Opened 3 years ago Closed 3 years ago

<link rel=preconnect> appears to bypass content policies


(Core :: DOM: Security, defect)

Not set





(Reporter: dveditz, Unassigned)



(Keywords: privacy, sec-audit)

+++ This bug was initially created as a clone of Bug #1408867 +++

Looking at the code I don't see where <link rel=preconnect> checks with any content policies (unlike the similar rel=preload). How much this matters depends on the purpose of the content policy. For example, this doesn't cause any problems for the mixed-content blocker since no content ends up in the document and no cookies are sent. Matters a lot to any use that's trying to police connections/loads in order to prevent privacy leaks (privacy add-ons? tracking protection?) since information can be embedded in the subdomain names.

Probably not a huge deal for Content-security-policy since CSP doesn't try to prevent all exfiltration (navigation isn't blocked) and the preconnect can't result in any content inserted into the document.
Tom: is this something Tor needs to worry about? I assume--but haven't checked--that the preconnect goes through the proxy and I don't know if Tor relies on content policies. HTTPS Everywhere might miss these, but since no response is incorporated into web content it's just a potentially wasted insecure connection.
Flags: needinfo?(tom)
Keywords: sec-audit
I don't believe Tor is affected by this, but I'm add Georg and Arthur just in case.
Flags: needinfo?(tom)
I think we are good with <link rel=preconnect> regarding proxy obedience. And, no, we don't rely on content policies. So, all in all I'd say we are not affected.
I guess this is OK as-is -- it's not really "content". It's just warming up the connection so it doesn't make sense to send through the content policies.
Closed: 3 years ago
Resolution: --- → INVALID
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.