feat: Allow CSP per org_domain

[Crash--]

This change automatically adds *.org_domain to all Content Security Policy directives when an instance has an org_domain configured. This allows loading resources (such as chat applications) hosted on the organization's domain and its subdomains.

[Crash--]

@nono what do you think about that?

[nono]

Well, I'm not a fan of this change. It's not catastrophic but it weakens the in-depth defense. Maybe we can change only some CSP rules. For example, I don't see any issues with allowing the new domains for img-src, but default-src and script-src are more powerful.

[Crash--]

How can we address scenario like this one:

• I've my OIDC provider located at oidc.mycompany.fr
• I've wrapped an application (like what we do with chat & mail) that relies on this OIDC provider. This application handles by itself the OIDC flow, so the application makes request to oidc.mycompany.fr . This application is served on mycompany-app.twake.app.

Scenario 1:

• Authorize *.mycompany.fr (this PR)

Scenario 2:

• Authorize only oidc.mycompany.fr. In other words, authorize only the needed domain. And since we do DNS validation & check elsewhere, we can add / remove these authorizations when needed.

Scenario 3:

• Serve the application on twake-app.twake.mycompany.fr . But even in that case, we should open CSP to *.mycompany.fr (or only oidc.mycompany.fr). So I don't this this scenario changes something.

Do you have something else in mind?

[Crash--]

Scenario 4: Only open needed CSP for twake-app slug.

[nono]

Do we really need to open the CSP for this scenario? We should try and look what CSP rules is blocking, but I wouldn't be surprised if it works without opening new CSP.

For OIDC, we need URL navigation (GET), and server to server communications. For server to server, the CSP doesn't apply. For URL navigation, I'm not sure. It may work with the current CSP, or we may need to update one rule (form-action? connect-src?).