Clarify behavior for cached favicon loads #390
Description
It seems some browsers remember the last favicon it used for a site and attempts to load that favicon for any resource that doesn't link to an icon. So, for example, when loading a text/plain document (that doesn't have any Link: <...>; rel="icon" header), the browser will attempt to load the last favicon for the site from whatever URL it loaded it from, or it will try /favicon.ico. Either way, unless the favicon is whitelisted in CSP, a CSP violation will be reported in some of these browsers. In some cases, the violation is even reported to the report-uri.
This makes it difficult to deploy a default "deny all" CSP policy like base-uri 'none'; default-src 'none' for non-HTML resources on a site, as these false positives (especially when reported using report-uri) are overwhelming. Note that it is often difficult to whitelist ONLY favicon URLs in such default policies for various reasons.
IMO the correct behavior is to use the cached favicon without blocking it with a CSP violation (and without reporting a CSP violation in the console or to the report-uri). CSP should only be applied when the resource specifically requested the favicon via a Link: <...>; rel="icon" HTTP header field o via a <link rel=icon> link. The purpose of CSP is to protect against injections (especially XSS). When there is no link to the favicon then nothing has been injected so there's no attack to block or report.