Content Security Policy Issues

  • Resolved farnely

    (@farnely)


    5 months ago

    I’ve implemented a CSP using nonces which is working fine for the parts I have full control over but I’ve hit a wall where tinymce and the screen reader are concerned. Despite using filter hooks script_loader_tag, style_loader_tag, wp_inline_script_attributes, wp_print_inline_script_tag and wp_print_inline_style_tag to add nonces, there are 3 tinymce scripts that are missed out (and so fail CSP) and ally.min.js applies inline styling to “something” (couldn’t say what).

    How do I fix this?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Mehraz Morshed

    (@mehrazmorshed)

    5 months ago

    Hi @farnely,

    As far as I know, TinyMCE loads scripts in ways WordPress can’t fully control. These scripts don’t all use WordPress’s normal loading system. Some come directly from WordPress core. Some are added by JavaScript after the page loads. Some are created by TinyMCE itself when it runs.

    Because of this, WordPress’s hooks for adding security codes never run for these scripts. Your security code system never sees them. That is why your security rules block exactly three TinyMCE scripts. They are either hard-coded or made when TinyMCE starts working.

    Mehraz Morshed

    (@mehrazmorshed)

    5 months ago

    Since you cannot use WordPress hooks for scripts loaded this way, you can try a different approach for these special TinyMCE scripts, add your security codes directly to the Content Security Policy header for these specific scripts.

    You need to find the exact script sources from your browser’s error messages. Then add these sources to your security policy using ‘unsafe-inline’ or calculate script hashes for each one.

    Mehraz Morshed

    (@mehrazmorshed)

    5 months ago

    @farnely,

    Please note that using ‘unsafe-inline’ is not safe. It turns off your script protection. This lets any script run on your page, even bad ones. Hackers can use this to attack your site.

    Finding and using the exact script hash is the safe way. This only allows that one specific script to run. This keeps your protection working while letting TinyMCE work. But you must get the hash exactly right, and it may change if TinyMCE updates.

    For your admin area only, using ‘unsafe-inline’ might be okay if all admin users are trusted. For your public site, using hashes is much safer.

    Thread Starter farnely

    (@farnely)

    5 months ago

    @mehrazmorshed

    Oddly, I had tried adding the hashes from devtools but they didn’t work. I wondered if perhaps a mixture of hashes and nonces wouldn’t work. I’ve tried it again today and now it works!! I must have made a mistake somewhere in my pasting.

    So relieved :-). Many thanks!

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

You must be logged in to reply to this topic.