Content Security Policy for Swagger UI(OpenAPI)
Today in this article, we shall see how to define Content Security Policy (CSP) for Swagger UI (OpenAPI)
While defining Content Security Policy(CSP) in API Swagger UI might show a blank page or don’t load API documentation properly.
Today in this article, we will cover below aspects,
This behavior was recently observed when CSP was added as a security header to the ASP.NET Core application.
I was getting the error “Refused to execute inline script because it violates the following Content Security Policy directive” for Swagger.
What is the use of CSP?
A CSP header enables you to control the sources/content on your site that the browser can load.
So this header gives you the ability to load only resources needed by the browser.
A Content Security Policy (CSP) helps protect against XSS attacks by informing the browser of the valid:
- Sources for content, scripts, stylesheets, and images.
- Actions are taken by a page, specifying permitted URL targets of forms.
- Plugins that can be loaded.
After I had enabled the CSP in API, I observed Swagger UI showed a Blank screen with the below error,
Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self'”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-hQoyAYxxdlQX6mYg//3SgDUdhiDx4sZq5ThHlCL8Ssg=’), or a nonce (‘nonce-…’) is required to enable inline execution.
I had my CSP header defined as below in ASP.NET Core API,
context.Response.Headers. Add("Content-Security-Policy", "default-src 'self';");
Resolution – Content Security Policy (CSP) for Swagger UI (OpenAPI)
This was after the initial trivial, was able to fix the issue due to strict Content Security Policy configuration.
Below is the configuration, I was able to fix the issue.
("Content-Security-Policy", "default-src 'self';img-src data: https:;object-src 'none'; script-src https://stackpath.bootstrapcdn.com/ 'self' 'unsafe-inline';style-src https://stackpath.bootstrapcdn.com/ 'self' 'unsafe-inline'; upgrade-insecure-requests;");
I was able to successfully fix the swagger error with the addition of the above header.
Fixing the issue additional Guidelines
- You could try something similar to settings or small changes or tweaks. Only add permitted URLs.
- You might need to change the script-src location (pointing to Google, etc .) as per your requirements to make it work.
- Using
unsafe-inline
defeats much of the purpose of CSP and violates safe CSP practices. However, considering the swagger limitation, you could try this option.
- Other alternate methods to allow are as below,
- Use Nonce Allow Inline Scripts
- Use Hash Allow Inline Scripts
References:
Do you have any comments or ideas or any better suggestions to share?
Please sound off your comments below.
Happy Coding !!
Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.
Hi,
I think Favicon will still stay blocked by this.
Agree completely on this, inline-scripts and data object for images are bad practice and violate a safe CSP.
I have had to create a custom swagger/index.html file moving inline JS into .js files and replace the annoying data objects for images with actual image files; using CSS to overwrite the content. It’s not ideal but it keeps SecOps off my back with a secure CSP.
Hey Colin, Thanks for your comment. Good to know you got it working using custom swagger. Thanks for sharing…
Hi,
I have the exact same issue, but I’m not familiar enough with react and swagger to fix it.
No issue with removing the unsafe-inline for script (js into another file), but I can’t fix the issue with the svg.
I got all the svg to files, but I can’t build (missing loader for those files, even if configured in the webpack/_config-builder.js)
Could you tell me how you did it or submit a PR to swagger-ui to fix it ?
This is the opposite of a fix security-wise.
Thanks Paul for your comments. Actually, we are specifying the only verified and permitted URLs in CSP (which are needed for the application to work fine).
Ok, I was too unspecific.
As for this case, with Swagger, you are correct in allowing certain styles as “unsafe-inline”.
Injected inline-styles are a bad habit of applications as they could and should all go for CSS. Anyhow, the security risk is lower than with scripts. Genereally, maliciously injected styles can wreck your page – or show ads which noone wants to see.
So, with inline scripts, you need to be quite careful. While it is a better solution to allow certain and only a little amount of inline-scripts with “script-src: ‘sha256-abcdefg12345…'”, a good app security would already take restrictive CSP into consideration.
So to say: Swagger should fix up and NOT use ANY inline-scripts. Your solution works – but it’s a workaround.
thx a lot
Welcome Diego. Glad it helped you!
Thanks man
You welcome Janakira