Clarify behavior for cached favicon loads #390
Comments
|
I agree. If the favicon (or any of the increasing number of icons/tiles/touch etc) are not explicitly defined by the page, they should not generate/report a CSP violation. The volume of such CSP violations in logs due to properly restrictive img-src/default-src mean the noise floor is raised significantly reducing the effectiveness of report-uri. We end up with no choice but to be heavy handed with filtering meaning we are more than likely going to miss real violations. |
|
If it were possible to circumvent the favicon load with a data url plus hash-based integrity, it would remove all noise from favicon requests without punching a hole in the CSP by blindly trusting 'data:'. Something like the following: <head>
<meta http-equiv="Content-Security-Policy" content="img-src 'sha256-W29iamVjdCBBcnJheUJ1ZmZlcl0='" />
<link rel="icon" href="data:," integrity="sha256-W29iamVjdCBBcnJheUJ1ZmZlcl0=">
</head> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 thereport-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.The text was updated successfully, but these errors were encountered: