-
Posts
-
Hi I saw someone else raised this same issue.
We have also added X-Content-Type-Options: nosniff to all of our enfold sites.
This is a modern browser security feature.Refused to apply style from ‘https://www.domain.com/wp-content/uploads/dynamic_avia/avia_posts_css/post-2810.css?ver=ver-1704186957’ because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.
This is still a problem.
Disabling the Post css generator with a snippet seems to solve the problem but this isnt a real solution.
Can you look into this? The mime type for the generated css file is incorrect which is causing the issue.
i do have this nearly on all my installations in the htaccess file:
<IfModule mod_headers.c> Header set X-Frame-Options "sameorigin" Header set Referrer-Policy "strict-origin-when-cross-origin" Header set X-XSS-Protection "1; mode=block" Header set X-Content-Type-Options "nosniff" Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" Header always set Content-Security-Policy "upgrade-insecure-requests" Header always set Permissions-Policy "geolocation=(), midi=(),sync-xhr=(),accelerometer=(), gyroscope=(), magnetometer=(), camera=(), fullscreen=(self)" </IfModule>and had never such problems – but maybe you are right – it could be matter of inline css files. I do allway set this to my child-theme functions.php:
function custom_avf_post_css_create_file( $create ){ return true; } add_filter( 'avf_post_css_create_file', 'custom_avf_post_css_create_file', 10, 1 );@Guenni007
I can confirm that almost 100 enfold sites on my server had the same issue when nosniff was enabled.I have since done an emergency setting change to turn off the post css file generation. I already had the code sat there because it makes Enfold work better with Cloudflare/any cdn by inlining the css background images.
I did make my header changes via Plesk control panel instead of ht.access though. So that could be a contributing factor but unlikely.
I’ll take a look over your other security settings. Just trying to tighten up a few of my sites security. Thank you for sharing this.
Hi,
thinkjarvis Thanks for your patience, and thank you Guenni007 for your feedback.
I tested the above code in my .htaccess and I found no errors and then I checked with this online tool to ensure MIME sniffing was disabled:
but I don’t have a Plesk server, I have a LiteSpeed with cPanel, perhaps this is the cause, try making the change in the .htaccess file instead.Best regards,
Mikeif i test my page on : https://securityheaders.com/?q=https%3A%2F%2Fwebers-webdesign.de&followRedirects=on
you can read the description of:
x-content-type-options: X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is “X-Content-Type-Options: nosniff”.
So your advice is to change the mime types for those generated post css to : text/css
but as far i can see on : class-post-css-management.php – line 919:
return '<style type="text/css">' . $this->new_ln . $rules . '</style>' . $this->new_ln;isn’t this responsible for those css settings?
__________
i set the filter ( avf_post_css_create_file ) now on one of my testinstallations to true ( only then files are generated inside dynamic-avia folder) – and switched of merging.
On dev tools i checked if i find some text/html in DOM – but nothing to find.Hi,
When nosniff is used the default type is text/css others are blocked, I understand this to mean that there is no need to add text/css.
Since I can not reproduce the error using X-Content-Type-Options “nosniff”, I believe this is related to the server type, perhaps thinkjarvis could test with the rule in his .htaccess and see if that helps.Best regards,
MikeHi Mike,
I just want to make sure you have investigated this properly. I am not asking you to use security tools to check the headers.
To troubleshoot this propery and recreate the issue:
1 – Enable the post css create file (default settings)
2 – Ensure NoSniff header is set.
3 – Log out of wordpress and browse to a few pages to generate the post css files
4 – Go to a private browsing window and visit those same pages and check the console.
5 – The problem is immedietely noticable on pages that use a colour section with a background image set. The background image will be missing because the post CSS file is blocked by the no sniff settings.This occured on every single Enfold site on my server. So ive got the post css generation turned off on all sites as a workaround.
Let me know if you follow these steps whether you still see the problem.
Hi,
Thanks for the feedback, I have followed these steps, nosniff is set in the header, post-xxx.css files are generated on the pages, and I checked incognito on Windows in Chrome, Firefox, Brave & Edge and color section background images show correctly and I have no console log errors:
Best regards,
MikeHi Mike,
Thanks for confirming. I’ll try adding the headers via htaccess instead of php settings in plesk and see if it still occurs.
Will report back when I get the chance to test this.
Weird problem!
99% sure I have found the cause of the problem.
I have not used the additional headers box in plesk apache and nginx settings.
Instead I have added the nosniff to the nginx, http and https directives.I’ll run a test and let you know if doing it this way works properly.
More annoyed that I have applied this to all of my sites and now will need changing for all….Fun afternoon for me…
I’ll get back to you once I’ve tested this properly and confirm no issue.
- You must be logged in to reply to this topic.