Inline script in index.html violates Content Security Policy

[ejweber]

I am attempting to host Swagger documentation on a server that is accessed through a proxy. The proxy adds the Content-Security-Policy: script-src 'self' header to all responses it sends back to a client. The swagger-api/swagger-ui maintainers removed inline scripts from index.html in this PR, and the associated commits were included in the swaggo/files project in this commit. However, swaggo/gin-swagger hardcodes an index.html template that still makes use of the inline script.

I'm unfamiliar with the swaggo/gin-swagger project at large, but it looks like it might be potentially tricky to update the template while maintaining configurability. Still, various security scanners, etc. are interested in ensuring that web servers are "properly" using Content Security Policies, and security policies in my organization make it difficult or impossible to use swaggo/gin-swagger while the inline script remains. I think it's possible that other users will have similar issues.

[ubogdan]

A configurable 'Content-Security-Policy' header can be added to the git-swagger to provide this feature.

If this is a high priority for you, please contribute, and I will be more than happy to assist you with a CR.

Thanks.

[ejweber]

Thanks for the reply, @ubogdan. Unfortunately, I'm not sure your suggestion will meet my needs. To be clear, I don't need gin-swagger to return a different Content Security Policy header. Even if it did, the proxy I am using would add the Content-Security-Policy: script-src 'self' header anyway. My issue is that gin-swagger actually does use an inline script on its index.html page. This is something the "upstream" swagger-api/swagger-ui project has moved away from. However, this project does not use that project's current index.html.

[ubogdan]

We cannot use the original files because we want to offer some way to configure the swagger UI. We can return the static index.html file from swagger files, and we can render the js file "dist/swagger-initializer.js" using "html/template" package.

Unfortunately, the holidays are knocking on our doors, and I'm busy these days. Any contribution may be very appreciated.

[ejweber]

This suggestion makes sense to me. Thanks for taking a look!

Full disclosure, I already pivoted away from using gin-swagger to host the docs (though I'm still using it to generate them, and this is working great). While I think this is a useful improvement, I doubt I'll get to it anytime soon either. I know enough to pry at the issue, but I'm far from a front-end developer, so I'm not confident in my ability to efficiently rework the way the UI is rendered in a way that doesn't break others. I mostly felt it was important to open this issue in case others run into something similar and are struggling to understand what's going wrong. If you (or me, or someone else) finds the cycles to implement your suggestion, so much the better!

[limistah]

@ejweber @ubogdan

I believe this can still be achieved using the "html/template" package.

The swaggerIndexTpl can have <script src="./swagger-initializer.js" charset="UTF-8"> </script> on Line 294

And there could be another template to generate the script at the same path as the index template that would contain all of the scripts at L295-L323

if this sounds like a feasible solution, I can work on this.

[ubogdan]

@limistah This is an OOS project and anyone is free to contribute.

My concern is about testing the implementation.

Thanks.

[limistah]

Great then. I believe it should be testable

…

On 6 Sep 2023, at 09:05, Bogdan U ***@***.***> wrote: @limistah <https://github.com/limistah> This is an OOS project and anyone is free to contribute. My concern is about testing the implementation. Thanks. — Reply to this email directly, view it on GitHub <#249 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHLK7V7PX7HQJEBLS5VSAEDXZAVDHANCNFSM6AAAAAASP57RW4>. You are receiving this because you were mentioned.

[limistah]

@ubogdan I made a PR for this
Find it here: #280