4 ms·
setting it via a meta-tag kind of defeats the purpose of course. It's much easier to inject a policy clearing meta tag (or change an existing one to contain som
by pilif 11y ago
setting it via a meta-tag kind of defeats the purpose of course. It's much easier to inject a policy clearing meta tag (or change an existing one to contain something invalid) than it is to forge a non-strict header.
- ptoomey3 11y agoWe set a CSP policy via meta-tag on our static error pages as belt and suspenders protection: (view source on https://github.com/500.html https://github.com/500.html). Setting this policy does two things. First, it ensures we have a policy set in case a server-side error occurs before we append the CSP header for a given request. Second, it actually makes our policy more strict on those pages even if the header is present. To your point about a "policy clearing meta tag", this shouldn't be possible. Based on our testing, CSP set via a meta-tag can only make any existing policy more strict. In other words, if your header policy has "script-src: assets-cdn.github.com" an attempt to broaden that policy (i.e. add a new source) with a meta-tag will fail. The only thing the meta-tag could do is reduce the policy with something like "script-src: 'none'".
- gose1 11y agoPolicies set via meta tags can only be made subsequently more restrictive: https://w3c.github.io/webappsec-csp/#multiple-policies https://w3c.github.io/webappsec-csp/#multiple-policies.