-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A default content-security-policy is revealing the hidden honeypot #597
Comments
The interesting thing is: we don't even create a But that might also be disallowed in a strict CSP setup. I don't see any issue having an external CSS file that gets loaded in the frontend. With HTTP2+, it's also not a performance issue. But then we should make sure to only load it on pages with the comment form, right? |
It's also the only inline style we have. So, it might really make sense. Even though I would usually print something like this in a Maybe add this with a filter to control to either add a |
Adding a filter to switch to a file would be best. If someone has a CSP or want to implement one, there would be a solution then. |
I began to implement a filter allowing to decide between using a file and inline CSS. But this would be a messy solution, since we would need to duplicate the CSS into the file and the inline attribute. Instead, I've implemented a filter to change the inline styles. One could use them to just use an empty style attribute and then have the necessary styles loaded in an external file (either in their theme or in a CSS file then enqueue themselves). Using a file by default might "break" some sites who are using techniques to combine external file. This filter is least likely to break any existing site, while still offering a solution for those using a strict CSP. We could even create a GIST explaining how to use it and link to that one in the plugin support ticket. |
From the support forums:
https://wordpress.org/support/topic/honeypot-textarea-visible-with-strict-csp-header/
More context:
https://content-security-policy.com/examples/allow-inline-style/
It looks like the only way is to allow "unsafe-inline" which would be decremental to security. Adding hashes or nonces would need a connection between our code and the CSP implementation which is not available.
Adding a CSS file would indeed fix this issue.
Thoughts?
The text was updated successfully, but these errors were encountered: