Hello!
This is certainly an issue we’ve seen before and has to do with the CSP set at either a server level or set as meta tags within the HTML document. We certainly do have inline scripts that run after the Google reCaptcha script is enqueued which was brought over from the original Contact Form 7 v5.0.5. Moving this to a general script and enqueueing it in a normal WordPress method may be an option we could explore which would solve the unsafe-inline
issues.
The following errors:
Application for access to cookie or storage "https://www.google.com/recaptcha/api2/anchor?ar=1&k=key 'is blocked because we Block all third-party requests for access to storage and content blocking is enabled.
Appears to be an issue with the reCaptcha library itself and not something that can be solved by pushing an update to the plugin.
– – – – – – – – – –
Exploring the possibly of moving an inline script into an external script is appealing but we do not believe that will solve all your problems here. We would suggest exploring your CSPolicies to create exceptions for the time being and verifying these policies are entirely necessary for the security of your website.
On our end we will do some testing to see why the original author of the code decided to use an inline script and the implications of moving this inline code into an external script.
– – – – – – – – – –
For reference, here’s a similar issue involving CSP headers and this plugin.