Skip to content

Conversation

@Crash--
Copy link
Contributor

@Crash-- Crash-- commented Jan 16, 2026

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-- Crash-- requested a review from a team as a code owner January 16, 2026 15:59
@Crash--
Copy link
Contributor Author

Crash-- commented Jan 16, 2026

@nono what do you think about that?

@nono
Copy link
Member

nono commented Jan 19, 2026

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--
Copy link
Contributor Author

Crash-- commented Jan 19, 2026

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--
Copy link
Contributor Author

Crash-- commented Jan 19, 2026

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

@nono
Copy link
Member

nono commented Jan 19, 2026

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?).

@Crash--
Copy link
Contributor Author

Crash-- commented Jan 29, 2026

Finally we only need a CSP iframe-src on matrix.orgDomain. Is it ok?

We have a check somewhere in the process to check that "matrix.orgDomain" is targeting our infra. But we don't have yet this information from the stack side. Maybe if it's needed we can try to find a way to set this boolean somewhere on cozy-stack.

@nono what do you think?

@nono
Copy link
Member

nono commented Jan 29, 2026

For me, it is OK.

@shepilov
Copy link
Contributor

Finally we only need a CSP iframe-src on matrix.orgDomain. Is it ok?

We have a check somewhere in the process to check that "matrix.orgDomain" is targeting our infra. But we don't have yet this information from the stack side. Maybe if it's needed we can try to find a way to set this boolean somewhere on cozy-stack.

@nono what do you think?

for me it looks safe if it's not an asterisk, we won't have any forgotten and arbitrary domains.

This change automatically adds matrix.org_domain to frame-src
Content Security Policy directive when an instance has an
org_domain configured. This allows us to load synapse(chat)
from the orgdomain
@Crash-- Crash-- force-pushed the feat/CspByOrgDomain branch from 9bff11d to db439d2 Compare January 29, 2026 09:37
@shepilov shepilov merged commit ecb93a6 into master Jan 29, 2026
4 checks passed
@shepilov shepilov deleted the feat/CspByOrgDomain branch January 29, 2026 10:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants