Improve default config

While there's no backwards-compatibility concern with narrowing the default config, is this something that should be done in 2.0.x so that it's clear in the release notes that people who are familiar with the current 1.x default config should expect additional warnings or blocked functionality when using 2.0.x?

script-src 'self' 'unsafe-inline'

While I would like to add script-src 'self' to the default enforced config, since Drupal 10.0+ (with CKE5) no longer requires inline scripts, I think that it is still too likely to cause issues for existing sites trying to enable a policy by blocking inline content for snippets that are commonly provided by third-party widgets. However, the current default, by not having any default-src or script-src directive, does not restrict 'unsafe-eval'.

* instead of 'self' would allow third-party scripts not included through a library by default, but a user could allow a necessary domain through the config UI if needed.

----

style-src 'self' 'unsafe-inline'

core/drupal.ajax still requires inline CSS prior to 10.1 - the default for 'unsafe-inline' could be set dynamically for older versions with hook_install, or the issue could be circumvented by adding changes in the 2.0.x branch and bumping the minimum core version to ^10.1.
Would enforcing no inline CSS by default be less likely to block functionality than blocking inline scripts? I think third-party widgets are the main concern for both scripts and styles.

----

form-action 'self'

seems reasonable to include in the report-only policy, or even enforced, to prevent form data being sent to third parties (e.g. a malicious form injected into the page with unsanitized HTML, or altering a form's action)

----

manifest-src 'self'

These feature seems unlikely to use an external domain?

----

worker-src 'self'

this falls back to script-src, but it could be good to block third-party scripts (from library definitions) from being able to run workers by default.

----

webrtc 'block'

I don't think webrtc is commonly used; someone using it would likely be able to easily notice and update a policy blocking it

----

base-uri 'self'

----

connect-src, frame-src, font-src, img-src<code>, <code>media-src

I think these all commonly enough require external domains, so would need to be * if a more restrictive default-src 'self' was implemented.

----

default-src 'self'

Adding a default restrictive value for default-src, and other directives (e.g. img-src) having more lenient default * overrides, seems like a safer policy approach but could be more difficult to manage for users less familiar with CSP.
Having the enforced and report-only policies use different approaches (strict-by-default versus lenient-by-default) could be confusing?

I think I'm happy with these changes for now.

Automatically closed - issue fixed for 2 weeks with no activity.