search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
210 stars 78 forks source link

Should font-src reporting kick in on font-face reference or font request? #677

Open robinwhittleton opened 2 months ago

robinwhittleton commented 2 months ago

I ran into a problem that I thought was a browser bug (WebKit / Chromium) but looks like possibly an underspecification.

If I define a CSP that blocks all external fonts (font-src 'none'), then write a @font-face definition that includes a font I correctly see that font being blocked in all current browsers. But if I add a unicode-range definition to that @font-face that just contains a character not in the initial page load, I would expect to see no CSP report. Currently WebKit, Chromium and Gecko all throw an error as soon as the font is referenced in the CSS, regardless of whether it’s loaded or not. A testcase is available at https://bug-277852-attachments.webkit.org/attachment.cgi?id=472095 that demonstrates this.

I’ve read the CSP3 spec to see what the expected behaviour is, and I think that it’s in line with my expectation. The font-src section talks specifically about requests being the trigger. But it also says that “fetches for the following code will return a network errors” despite the code referenced only being CSS and not a font file.

Can anyone clarify this? Is it just requests for font resources that should trigger a font-src exception?

annevk commented 2 months ago

Are browsers actually delaying the fetch for the font or are they eagerly requesting it? CSS used to notoriously underdefine its fetching infrastructure and while that has improved somewhat, I'm not sure it would cover nuances such as this.

robinwhittleton commented 2 months ago

Looking at my test case (with a button added that dynamically inserts a matching character):

Without a CSP statment Firefox gets it right: it only loads the font file when a character matching the specified unicode-range is added to the body. With a CSP statement we get a CSP error fired on page load, and another fired when a matching character is added.

Without a CSP statment Safari and Chromium (tested with Edge) get it wrong: they loads the font file regardless of whether the specified unicode-range matches a character in the page. With a CSP statement we get a single CSP error fired on page load and no more as the character is added. (I’m a little confused about this, as in my usual experience unicode-range is honoured by Safari and Edge.)

annevk commented 2 months ago

Maybe @Emilio can comment on what is happening in Firefox.

Anyway, the presence of CSP should not influence when fetches happen and CSP also says nothing of the sort. I don't really see an issue with CSP here. Possible issues:

  1. CSS does not define fetching accurately enough.
  2. Browsers do not handle font fetching correctly. (This seems almost certain given the results you mention, though different issues for different browsers.)
emilio commented 2 months ago

It might be that browsers fetch the font to compute other general font metrics, fwiw...

annevk commented 2 months ago

Which should probably be defined in CSS, but would indicate that no browsers might be at fault here.

robinwhittleton commented 2 months ago

Hah, right, that somewhat defeats the purpose of unicode-range then, for example when you have 30+KB of CSS specifically to make sure that your font chunks aren’t all loaded at the same time. But I guess that’s outside the purview of this forum.