Still having SRI issue

As has been discussed many times on this support forum before, this plugin does not add SRI attributes to resources loaded from the same-origin domain. If your website is example.com, then scripts loaded from example.com do not need (and, according to the official specification, should not have) subresource integrity attributes added to their calling elements.

Website scoring tools such as the Mozilla Observatory are a useful visibility tool for developers who want to learn more about Web technologies. They are not intended to be and should not be used as some kind of unilateral “pass/fail” test.

Hello Meitar!

Your plugin seems really great!

I’m starting to try it out, but ran into @fxdesca78’s problem as well: I’m trying to use the most restrictive CSP possible, but — even if I get everything right on the theme’s side (I’m actually trying NOT to use any JS) — I’m running into issues on the WP-Admin side: without white-listing ‘unsafe-inline’ and ‘unsafe-eval’, some pages (like post the post editor, or plug-ins like Akismet) simply don’t work.

Do you think it could be possible to parse inline scripts?

Do you think it could be possible to parse inline scripts?

From this question, I’m not sure you understand what SRI is designed to do, or perhaps you simply misunderstand one of its foundational concepts. SRI does not apply to inline scripts because it makes no sense to do so; the inline script was delivered as part of the same HTTP resource as the HTML, after all.

I’m running into issues on the WP-Admin side: without white-listing ‘unsafe-inline’ and ‘unsafe-eval’, some pages (like post the post editor, or plug-ins like Akismet) simply don’t work.

WordPress’s new Block Editor requires JavaScript, so you cannot simply disallow all JavaScript via CSP headers and expect your browser to load the Block Editor correctly. In other words, this is expected behavior because by disallowing inline scripts, you block the required WordPress admin scripts that are delivered inline.

You are correct that it would be “more secure” not to require any inline scripts but AFAIK, that is not the case in WP core right now.

Thank you for your prompt response!

From this question, I’m not sure you understand what SRI is designed to do, or perhaps you simply misunderstand one of its foundational concepts.

It very well may be that I don’t fully understand SRI (although I’ve been reading specifications and developer documentations whenever I bump into any problems, and honestly trying to grok before asking questions).

SRI does not apply to inline scripts because it makes no sense to do so; the inline script was delivered as part of the same HTTP resource as the HTML, after all.

You’re totally right. I was confused with the example that was presented in the MDN entry for CSP’s script-src.

Thanks again for the answer! I think I may need to scrape inline scripts and generate a nonce attribute that is also added as a value to the Content Security Policy. At least, that’s what may be recommended by CSP2.

Thanks again for the answer! I think I may need to scrape inline scripts and generate a nonce attribute that is also added as a value to the Content Security Policy. At least, that’s what may be recommended by CSP2.

Yes, this is the correct way to handle the issue you’re describing. SRI attributes are not going to be useful for you, so this plugin (while useful for other reasons) is not going to help you here.

For what it’s worth, you can follow WP Core Trac enhancement ticket #39941 for updates on the progress of making the WP Admin interface work with the kind of CSP policy you want.

You may also be interested in any of these plugins, which purport to handle CSP headers for you in a semi-automated way. At the moment, though, the recommendation is to simply lock down your /wp-admin/ area as much as you can using other mechanisms, since it’s incredibly costly from a code and maintenance perspective to make WordPress play nice with super strict CSPs right now.

Those links seem very useful! Again, thanks for the support and advice, and sorry for the trouble!