A default content-security-policy is revealing the hidden honeypot

[Zodiac1978]

From the support forums:
https://wordpress.org/support/topic/honeypot-textarea-visible-with-strict-csp-header/

With a strict content security policy the inline CSS of the honeypot is ignored by the browser and the textarea becomes visible. This is the case for example with this HTTP header:

Content-Security-Policy: default-src 'self';

As a workaround I have moved the inline CSS to an external css file:

/* Antispam-Bee */
textarea#comment {
padding: 0 !important;
clip: rect(1px, 1px, 1px, 1px) !important;
position: absolute !important;
white-space: nowrap !important;
height: 1px !important;
width: 1px !important;
overflow: hidden !important;
}

Maybe the Antispam Plugin could itself include such a CSS file (additionally to the inline CSS) so the honeypit textarea remains hidden with a 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?

[2ndkauboy]

The interesting thing is: we don't even create a <style> tag. We use an inline style attribute: https://github.com/pluginkollektiv/antispam-bee/blob/master/antispam_bee.php#L1312

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?

[2ndkauboy]

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 <style> tag.

Maybe add this with a filter to control to either add a <style> tag or link a CSS file? Or would we just go with the external CSS file, causing some performance hit on slow hosting?

[Zodiac1978]

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.

[2ndkauboy]

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.

[Zodiac1978]

One more report on the forums:
https://wordpress.org/support/topic/csp-setting-script-src-elem-self-unsafe-inline-nonce-leads-do/

@2ndkauboy Can you look at this report? I think this is the same problem as mentioned above and the solution is the same, but it would be great if you can have a second look at it, if I am missing something new.

[Zodiac1978]

Looking at the description from the Strict CSP plugin it seems we could maybe solve it with using wp_print_inline_script_tag?