• Resolved haddlyapis

    (@haddlyapis)


    Hi there,
    after analysing my site for XXS issues (Cross site scripting), one issue in my console shows up that concerns a the FVM plugin:
    Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self' fonts.googleapis.com maxcdn.bootstrapcdn.com fonts.gstatic.com". Either the 'unsafe-inline' keyword, a hash ('sha256-RaP83aCN4eUnt+1kw6inLwKAQ80NxUjmEVXbt5rx2hk='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
    If i then click on the source of this warning it shows me the following function (note, only part of it pasting here):
    function fvmuag(){if(navigator.userAgent.match(/x11.*fox\/54|oid\s4.*xus.*ome\/62|oobot|ighth|tmetr|eadles|ingdo/i))return!1;
    My question to you: is there any way to put this function into an external JS file in order to not have inline JS?
    thx in advance for any help.

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Raul P.

    (@alignak)

    If you are updating your Content-Security-Policy settings to be that strict, you need to consider that inline javascript is a very common occurrence on wordpress, and I don’t know many themes or plugins that a hash on their inline scripts.

    Even you you manage to sort it out, there will be other plugins and likely even the theme itself causing those issues.

    For compatibility reasons, one should use “unsafe-inline”.
    This doesn’t mean your site can suddenly be hacked, only that unknown code can run.

    If you use a WAF (firewall) from example, by cloudflare and enable all the correct rules for wordpress, your site will be more protected that by fiddling with the content security policy.

    Limiting the CSP in this manner, should mostly be used if your site allows people to post content (like a forum, membership site, etc) and only if your site is not sanitizing their input.

    In order for someone to be able to inject a script into the page, they would already have to be able to access your site in some other way (a sql injection or some other php vulnerability), so javascript inline code, would be the least of your worries.

    That being said, the way to fix that would be to add sha256-RaP83aCN4eUnt+1kw6inLwKAQ80NxUjmEVXbt5rx2hk= to your content policy script-src, until the next FVM update where I may change the script to something else.

    script-src 'sha256-RaP83aCN4eUnt+1kw6inLwKAQ80NxUjmEVXbt5rx2hk=';

    That means, you you want paranoid security, you will first need to test the updates for each and every plugin and update your CSP if they ever change.

    Any script that is dynamic, will cause you issues as well, such as for example, the default wordpress nounces that exist on wp-admin and frontend page editors.

    I do not recommend limiting inline scripts, but you have full control over the code and know that it’s mostly static, then you can adjust your CSP rules on the server to specifically allow them by hash.

    This is a server setting, so you will need to adjust it.

    I cannot move that function to an external file, else it will increase the requests. Furthermore, it’s critical because it’s used before any deferred scripts.

    Plugin Author Raul P.

    (@alignak)

    my answer is pending moderation, so please wait for it. Thanks

Viewing 2 replies - 1 through 2 (of 2 total)

The topic ‘XXS report issue’ is closed to new replies.