Conflict with Content Security Policy

Are you referring to the script templates and whatnot to help render the dropdowns and instantsearch layouts?

If you have a link to where you’re seeing what you’re seeing and can point out the specific spots you’re referring to, I can provide a more comprehensive answer

support.botron.com

As an update, I’ve moved the scripts out of the PHP files and I’m loading them through a PHP function in my custom functions file. But this also seems to keep the script inline for some reason or another.

If you view the page source and search for var algolia you will see it.

Thanks for the prompt response Michael!

At least based on the part mentioning “search for var algolia”, I believe all those parts are safe to be public and stored as a window global in that algolia variable.

The parts of the Algolia plugin that do the lookups make use of those values and then on the server sides, I think it may use the “Admin API key” as potentially part of that process, and that key absolutely should be kept private and is not part of that frontend output.

You can read more about the API keys over at https://www.algolia.com/doc/guides/security/api-keys/

I’m pretty sure the Algolia devs had the admin key field set up in the WP Search With Algolia plugin before WebDevStudios took over continued maintenance and development of it, so that’s not something we did willy nilly.

The problem is, I cannot set a strict Content Security Policy because of this. I’m sure it’s safe, WP has a few inline scripts (also issues). But the second I turn on my CSP the plugin will not work. I have to enable ‘unsafe-inline’ which is a problem for security.

Also, not sure about this but, any way to work with wp_get_script_tag() to assit in this?

is this CSP plugin a publicly available one? or is it a paid premium one? We can definitely try to do our best with this, but I can’t make any guarantees at the exact moment. Part of why i’m curious about this plugin you mention, to perhaps help give us a better idea of what’s going on in the situation.

Its not a plugin. I’m just writing to the htaccess.

And because you have to pass this CSP check for other domain reasoning, having an open script policy is flagged.

So I tried cleaning it up by removing the script to its own file and registering it. But that still drops the same inline js.

Wordpress does nonce and apparently you can nonce the script with the server. But, this is above my knowledge bandwidth. So Im just a tad stuck.

Thank you for the continued support! I appreciate the conversation and your time!

What rules are you adding to your htaccess then? I’m still curious and hoping to better understand as much as I can here ??

Also curious what steps you took to move the scripts to their own files etc. Like did you edit the autocomplete/instantsearch templates, cut out the <script> tag sections and paste those into individual file(s) and enqueue those?

I feel like the algolia variable needs to be hoisted up to the global scope for as much readily accessible access to it, for other parts of the scripting around the Algolia usage, but I could be wrong.

I’ve since taken it down (the CSP) but what I had was similar to this:

Header set Content-Security-Policy “default-src ‘self’; “script-src ‘self’ cdn.for-some-js.com; (and so on adding “style-src” and such)

What happens is a bunch of errors happen in the console and you keep adding the external URIs to permit them running on the site. But for anything running on the main domain. However, inline JS will not run until you modify the CSP to something like such:

Header set Content-Security-Policy “default-src ‘self’; “script-src ‘self’ cdn.for-some-js.com ‘unsafe-inline’;(…)

And while the JS might be safe, the fact you have to use ‘unsafe-inline’ is a security concern.

As for the algolia plugin: I moved the php files to my theme directory/algolia
inside of that I put the 2 php files. I then I made a inc/js folder. I removed the JS between <script>…</script> and moved them into algolia/inc/js

This is my functions.php

// Load Algolia Autocomplete JS
add_action( 'wp_enqueue_scripts', 'bo_add_algolia_autocomplete', 999 );
function bo_add_algolia_autocomplete() {
    wp_register_script('bo-autocomplete', get_stylesheet_directory_uri() . '/algolia/js/algolia-autocomplete.js', array(),'1.1', true);
    wp_enqueue_script('bo-autocomplete');
}

Everything works regarding the plugin, with this separation. I was however hoping it would fix the inline JS aka CSP ‘unsafe-inline’ but it did not.

By any chance can we get this back to how it was where it isn’t quite working and let us see it in action, so to speak? I’m not sure I’m accurately recreating on a local install, so something I could see from your intended implementation would help out.

Also, I did find https://content-security-policy.com/examples/allow-inline-script/ which looks interesting and still decently safe, but by all means, evaluate yourself as well, in case you have knowledge I don’t on this topic.

I can but Ill need a day to get it going for you! Thank you, ill check the link too.

Oh yes I’ve seen this link. I just do not know how to set up a nonce. And then work it in.

We will be here when ready, though parts may be delayed with the weekend looming. Maybe if anything a staging version would work as well, for what it’s worth.