Facing issue in default WordPress after adding Content Security in httpd.conf

  • Hello Team,

    I really appreciate it if you help me to find a workaround for this issue quickly.

    We are facing an issue in default WordPress after implementing Content-Security-Policy in httpd.conf file. (i.e. ROOT File)

    Header append X-FRAME-OPTIONS "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always set Strict-Transport-Security "max-age=31536000"
Header always set X-Content-Type-Options "nosniff"
<strong>Header always set Content-Security-Policy "default-src 'self'"

    To draw your attention, I would like to inform you that We are trying to add in .htaccess. Header always set Content-Security-Policy “default-src ‘self’ script-src ‘self’ ” but it’s not allowing us.

    Pls, refer to the below screenshot for more details.

    https://prnt.sc/1q2n2xg
    https://prnt.sc/1q2n7qh
    https://prnt.sc/1q2qplm – Here you can see Editor is not working
    https://prnt.sc/1q2qwnc – Here you can see Editor + Upload Featured Image not working
    https://prnt.sc/1q2r87z – Here you can see comment Editor not working

    Please help ASAP. So, I can be delivered things to my client quickly.

    Thanks
    Bhavin

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

  • If you can still edit your post, please do so and remove your contact information, as that’s against the forum’s community guidelines.

    To draw your attention, I would like to inform you that We are trying to add in .htaccess. Header always set Content-Security-Policy “default-src ‘self’ script-src ‘self’ ” but it’s not allowing us.

    I’m not sure what you mean by “it’s not allowing us”. It seems to me your directive is doing exactly what you’ve asked it to do.

    Maybe before implementing such policies on your site, you should invest a little time to understand what those policies mean, and their implications.

    A good resource on CSP: https://content-security-policy.com/

    In your case, script-src 'self' (or default-src 'self', if there’s no more specific directive) blocks inline scripts from getting executed. That’s why your site is broken after your CSP implementation.

    You’ll need to use either hashes or a nonce to allow inline scripts to run.

    Please see:

    https://content-security-policy.com/script-src/

    https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

    Good luck!

    Thread Starter techforceglobal

    (@techforceglobal)

    Thanks, @gappiah For the quick responses.

    My WordPress Problem :
    As we have implemented Content-Security-Policy in httpd.conf file and apply only ‘”default-src ‘self'”. Due to this reason our DEFAULT WordPress getting an Error and not working properly.

    So, As a solution do I need to ADD the following things in httpd.conf File i.e. Root server File ?

    script-src ‘self’
    ‘unsafe-inline’

    If ‘YES’ do you think our security server levels will be degraded after applying the above tags? Pls, guide me to resolve this issue.

    Thanks.

    If ‘YES’ do you think our security server levels will be degraded after applying the above tags? Pls, guide me to resolve this issue.

    Adding ‘unsafe-inline’ degrades security in the same way as opening a port in your firewall degrades security. But the degraded security is still better than no CSP (or no firewall) at all.

    The secure way to allow inline scripts is with a hash or a nonse as I mentioned earlier.

    That’s easy to do if you’re building your own application and you control every bit of inline JS code.

    But when you’re dealing with a WordPress site with random themes and plugins injecting random bits of inline JS code all over the place, today I don’t know of any effective way to handle this — to implement strict CSP on a WordPress site.

    There’s some work underway though.

    Ticket 39941 added a handful of new functions to 5.7 that enables passing attributes, such as async or nonce to both regular and inline script tag attributes. This creates a path forward for enabling a Content-Security-Policy (or CSP) in Core, plugins, and themes.

    Additional work is ongoing to make WordPress core compatible with strict CSP out of the box. See tickets 51407 and 51438, both scheduled for 5.9. Of course, themes and plugins will still forever remain the achilles heel of WordPress security.

    Good luck!

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Facing issue in default WordPress after adding Content Security in httpd.conf’ is closed to new replies.