Is there a way to serve Intercom with Content Security Policy without style-src: 'unsafe-inline'

​@Gyuri van de Bilt ​​@steamroller ​@MattWD ​@kevindqc ​@Erin ​@Dries Hendrickx ​@Pascal Bourque ​@Stefan M ​@Evan P ​

It’s Mat from the Support Engineering Team 😀

I’ve manage to get in touch with the Security Engineers from Intercom and they offered an explanation for the unsafe-inline style-src.
 

Clarification on CSP and unsafe-inline for style-src

This topic seems to come up repeatedly, so I wanted to provide some clarity.
 

We’re aware that unsafe-inline is generally discouraged, especially for script-src, as it can lead to significant security risks. However, we are using it specifically for style-src, which is a different case.

We’ve done thorough research on this, and I am not aware of any practical, real-world attack enabled by style-src: unsafe-inline. Here’s why:
 

1. Style injection has very limited impact – It mainly affects the visual appearance of a page, which could potentially be leveraged in social engineering. There are some theoretical side-channel attacks, but they are highly impractical.

2. Older attacks like RPO (Relative Path Overwrite) or RSSPI – These were only relevant in Internet Explorer, and they’ve long been obsolete.

3. CSP is a backup mechanism – Ideally, style injection shouldn’t be possible at all. If it does happen, CSP can mitigate some risks, but the core issue is preventing style injection in the first place.

4. We need unsafe-inline for legitimate reasons – While removing it could be possible, it would require significant effort for almost no real security gain.

That said, we’re open to reconsidering if someone can demonstrate a real-world, impactful attack that our current setup enables. I’ve asked multiple people about this before, and I’m genuinely curious if there’s a practical exploit I haven’t considered.

If anyone has concrete examples, I’d love to hear them!

Hope this helps! 😊