Patrick Sletvold

Hi, and sorry for not responding earlier. Happy to see you figured it out.

You are indeed right that a str_replace should fix it, it was simply an oversight on my part not to consider that the chosen header could include newlines. Thanks for pointing it out!

There are probably other characters that can affect the output too, so I’ll have a close look at the specification for how the header is parsed by browsers. Should be included in the next update, I hope.

Best regards,
Patrick Sletvold

Hi, and sorry for not answering (I noticed you seemed to find a solution before I saw your post).

Thanks fpr the suggestions, they are greatly appreciated. Suggestion #2 should be resolved by the collapsible sections I’ve been implementing on the development branch, but I will note down the others and see if I can add them in the future. Due to computer issues I have been unable to do proper WordPress development the last while, but hopefully this should be resolved soon.

Best regards,
Patrick Sletvold

Yes, the interface is quite simple right now, and just maps directly to the text value of the directives. I have an upcoming version that has some improvements to some of that. At the very least the upgrade-insecure should really not be a text field, I agree. I’ll probably look into adding dropdowns where it makes sense too.

Best regards,
Patrick Sletvold

Hi @gadelaza,

The values are separated by a space. Only special values like ‘self’ and ‘unsafe-inline’ use quotes. The rest are just domain names, and including https:// is probably a good idea if you only expect that domain to be accessed over HTTPS. There’s a few other tricks you can do too, like using a wildcard character, which MDN has some nice examples for.

If I remember correctly, Security Headers will note that CSP is not on if you have it in Report-Only mode, since that mode does not affect the security of your site. If that’s the case, you should still see your configured Content Security Policy under raw headers further down the page. Using Cloudflare should not usually be a problem.

Best regards,
Patrick Sletvold

Hi,

Version 1.1.0 of the plugin includes support for frame-ancestors, along with a few other requested directives. It should be available for download now.

– Patrick Sletvold

Hi,

Version 1.1.0 of the plugin includes support for both require-trusted-types-for and trusted-types, along with a few other requested directives. In a future update, I plan on supporting the majority of the remaining directives.

– Patrick Sletvold

Hi @rmlumley, and sorry for not answering earlier. Turns out I forgot to subscribe to notifications here, so I didn’t see your message.

This is probably not the best place to ask about general CSP help, but I will try to explain what I think could be happening nonetheless. For a more in-depth explanation you would have to ask someone more familiar with the specifics of CSP.

The front page includes the following HTML snippet:
<link rel="next" href="https://morgridge.org/page/2/">
(This is not uncommon for sites, it just tells the browser the URL of the next page.)

I believe it is possible that Firefox is doing something like prefetching or preconnecting to this page, to improve load time if the user clicks the “next” link at the bottom of the page. (You don’t seem to actually have a next link, so I’m not sure why the link rel=”next” is added at all.)

This preconnecting (or whatever it is) would need to be allowed in the CSP, in the relevant directive. Since the correct directive is not set, it falls back to default-src, which I assume does not contain anything that would allow that connection.

I am not entirely sure what Firefox is doing here, but it is clear that it treats the link rel=”next” tag different from other browsers. It is probably not a major problem, but adding ‘self’ to either default-src or the relevant more specific directive (which I suspect might be connect-src, but haven’t confirmed) should make the error go away.

– Patrick Sletvold

Hi @digisavvy, and sorry for not answering earlier. Turns out I forgot to subscribe to notifications here, so I didn’t see your message.

I’m currently preparing an update for this plugin, so I will see what I can do with regards to adding some more directives, like the ones related to trusted types. The currently supported directives were chosen based on what I had a need for myself, but it makes sense to expand upon this.

Also thanks to @csplite for explaining the consequences of adding require-trusted-type-for. It is one of the directives that requires the most work to adopt, but after the next plugin update you should at least be able to do set the directive, should you wish to.

– Patrick Sletvold

Hi, and sorry for not answering earlier. Turns out I forgot to subscribe to notifications here, so I didn’t see your message.

I’m currently preparing an update for this plugin, so I will see what I can do with regards to adding the frame-ancestors directive. The currently supported directives were chosen based on what I had a need for myself, but it makes sense to expand upon this.

– Patrick Sletvold

Hello, sorry for not getting back to you earlier. I had even opened this page in preparation of writing an answer, but I got distracted with something else.

Yes, the main lazysizes script just has ‘lazysizes’ as the handle. That goes for both the optimized and the plain lazysizes script. When not using the optimized scripts, the other scripts has handles on the form ‘lazysizes-featurename’, you can find them here (on the lines with wp_enqueue_script).

Hi,
I’ll look into it and see what I can do, but it comes down to what my build tools support. I might be able to figure out something so it won’t cause an error however (though I would think the JS code being in its own function closure should make sure strict mode doesn’t affect other code already, but I’ll look into it). Then I’ll bundle it up together with some other fixes, and probably release it as a patch update. In the mean time, I assume a non-ideal workaround would be to exclude lazysizes from the merging of script files.

Hi, and sorry for the late response. As far as I know WordPress doesn’t have built-in support for filtering the whole markup though, while haven’t looked too much into processing it, with the right workarounds it should be doable. The reason I haven’t looked into it yet is, like the description for that plugin mentions, it would need to process more markup. And the workarounds needed could affect performance a bit too.

That said, I could probably add it in a future version. Not sure if you still need it by then, but I’m sure it could be useful as another option to try for other people too. The lack of support for this in WordPress core is also the reason why there’s specific integration with ACF. Without full markup processing either this plugin needs to integrate support for other plugins/themes, or they need to implement support for this plugin. Implementing this would lessen the need for such integrations, or at the very least serve as a fallback when they don’t exist.

– Patrick Sletvold

Hi dutze,

It is indeed very weird that option C doesn’t work, so I’ll have to look into that. I find it curious that the minification process seems to fix the error, but you’re right in that it would be the best option to enable both. The minimized option should noticeably improve performance, as it’s less code for users to download. The custom scripts reduces the amount of code as well, but the main benefit of that is it being only a single script file to download. That last part is not quite as big of a deal as before HTTP/2 became a thing, but should still help performance.

As for the no-JS fallback, I’ll just wait and see if I have time. I need to get out a small release for WP 5.5 support, so hopefully I can get any fixes necessary into that one.

Best regards,
Patrick Sletvold

Yes, that was the option I meant. Didn’t remember exactly what I named it (it’s called optimize_scripts_styles internally ??). I’ll look into the changes I made and see if any of them are incompatible. If you have the opportunity, would be very helpful if you could check with the minify option turned off too, in case that part of the process causes problems.

For the no-JS fallback it depends to some degree on the type of site. The overwhelming amount of users will have Javascript enabled, but some do turn it off intentionally usually for privacy of performance reasons. In very few cases it might be unsupported in the browser, but users of those browsers probably have other problems too. (As an aside, certain browsers, like Opera Mini, also have limited JS support but I don’t think the no-JS fallback would change anything there, as JS is technically enabled) It might not be a problem disabling the fallback, as long as the images are not crucial to the content of the site. That said, I could always look into why the fallback is failing with the picture elements in the first place. Could very well be a bug, as the picture element support is rather complex.

Best regards,
Patrick Sletvold

Hello @dutze!

Could you check if anything’s different if you enable/disable the optimized scripts option? My guess is that lazysizes bails out of lazyloading because it thinks the browser is not supported, and there’s some differences in the optimized script that might affect it. Also worth noting that the new/experimental blurhash option has somewhat limited browser support, but even if you’ve enabled that, the images should still lazyload correctly in older browsers.

Also, if the optimized scripts doesn’t change anything, it would be great if you could check the browser console. It’s not super easy to do on an iPad, but I think there’s some bookmarklet script that can open a mini devtools. If you have a Mac, the easiest is probably to connect to it through safari’s devtools. Let me know if you need more details, or if this step proves difficult though, I could look into reproducing it myself on an old iOS device if needed.

Best regards,
Patrick Sletvold