Styles don't load because they require unsafe-inline Content-Security Policy (CSP)

[docguytraining]

Our content security policy (CSP) includes: style-src 'self' docs.ourcompany.com;

However, when we load our api doc using OpenAPI explorer, the style sheet doesn't load, and the console fills up with CSP errors because we don't allow inline styles.

Can the styles be externalized into a stylesheet so sites with a strict CSP can display the stylized version?

[wparad]

At the moment this isn't possible. The reason that it isn't is actually due to the fact that there the dynamic stylings are calculated and injected in based on the theme set in the html attributes. We have been waiting for advanced functionality in CSS to be widely adopted so we can move from javascript to pure css here, but it hasn't happened yet.

To help us prioritize the need for this, could you explain the threat model associated with using the unsafe-inline in the style-src SCP?

[wparad]

We've reviewed this, and it seems that there are some places we can make improvements so that we have support a stylesheet, but there will always been inline styles in this component in some way. For instance, if I understand the request, it seems like you are saying we need to change every instance of

<button style="color: red">button text</button>

To:

<button class="redButton">button text</button>
<style>
  .redButton {
    color: red;
  }
</style>

That just isn't feasible, and unless I'm missing something obvious, it seems ridiculous to not allow that. Can you help me understand, what are we missing here?

Here's what we are going to do, I'm going to leave this issue open as a request to migrate the inline style attributes to classes.

We'll gladly accept a PR that transitions them to class based css stylesheets consistent with the rest of our usage.

[docguytraining]

Yeah. It's a requirement from our infosec team. I can get details. Basically, I work for a cybersecurity company, and we have some clients who have complained in the past about 'unsafe-inline' even for style-src. I haven't been given info on a specific threat model, but I can dig into that.

And the reality is that if you don't include unsafe-inline, you can't even use <style></style> on the page. All style definitions need to be in an external style sheet. But I get that that solution isn't perfect either.

I may need to see if we can stand up a specific server for our developer audience just for API doc and see if we can get away with unsafe-inline there.

[wparad]

We can easily get around the <style> by using the nonce-value option in the CSP, for where we are using it. Then you can pass that value in to us. The problem is that I can't fathom restricting all future development from using inline styles, since I too work for the security industry (on the app sec side), I'd love to know the attack vector with unsafe-inline, because if there is actually one there, then it would be a great signal for us to actually do this differently.

[wparad]

After extensive research on our side. we haven't been able to find any attacks that can utilize the unsafe-inline for style-src. It's worth mentioning that we did find one strategy that does utilize css via the image-src to perform attacks. That is, if you import malicious CSS into your site through pages, etc... And that CSS contains images or javascript, then the url(LINK) property can be abused to perform an attack. But that attack is blocked by the image-src attribute not the inline styles. (Here is the reference to that attack).

As such we cannot find any security issues with the CSP style-src: 'unsafe-inline', for right now, I am closing this issue.