Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not rely on CDN for swagger JS by default #389

Closed
pombredanne opened this issue May 18, 2021 · 4 comments
Closed

Do not rely on CDN for swagger JS by default #389

pombredanne opened this issue May 18, 2021 · 4 comments
Labels
enhancement New feature or request fix confirmation pending issue has been fixed and confirmation from issue reporter is pending

Comments

@pombredanne
Copy link

pombredanne commented May 18, 2021

Describe the bug

These settings

'SWAGGER_UI_DIST': '//unpkg.com/[email protected]',

    'SWAGGER_UI_DIST': '//unpkg.com/[email protected]',
    'SWAGGER_UI_FAVICON_HREF': '//unpkg.com/[email protected]/favicon-32x32.png',

are problematic on several levels:

  1. external data are fetched:
  • there could be external bad code injected in the case of a supply chain attack on unpkg.com
  • the users of an app that uses drf-spectacular can now be tracked too based on this external request
  1. no URL scheme is provided (therefore it could be plain HTTP AFAIK): the transport may not be encrypted and this could be a security issue with a machine-in-the-middle attack

Here I am using a local server which is HTTP and not HTTPS, and now this means that these data could be fetched over HTTP-only.

Expected behavior

These should be static resource instead or at the minimum be https:// by default This would make things much simpler IMHO.
Alternatively if there were a way to override the setting such that I could provide my own locally that would be a good too.

@tfranzel
Copy link
Owner

hi @pombredanne,

1a: absolutely, there could be an attack on unpkg. someone could also smuggle something into swagger-ui build with a neatly constructed github action. in that case we would also be vulnerable by using the swagger-ui github releases, and we need to get a release from somewhere.

1b: also true, but loading 3rd party hosted assets is probably more the norm than the exception in today's internet. who hosts all their assets themselves anymore?

nobody is forcing you to use the CDN. if you are so inclined, you are free to change those settings and host your swagger-ui build yourself. that is exactly the reason why the setting is there.

Alternatively if there were a way to override the setting

i don't understand. those are the settings. they are there to be changed. simply put a different value in your settings.py

we will not host copies of our dependencies ourselves. cumbersome to update and very little benefit in it. feel free to suggest a better industry-recognized CDN and we can talk.

2: yes, potentially but that is the point. however, i would say that loading the asset would be the least of your problems. also mixed content is bad. if you serve your swagger-ui over https, browsers will see the // and use the scheme used on the root request (which should already be https in 2021).

@tfranzel
Copy link
Owner

closing this issue for now. feel free to comment if anything is missing or not working and we will follow-up.

@tfranzel tfranzel added enhancement New feature or request fix confirmation pending issue has been fixed and confirmation from issue reporter is pending labels Sep 24, 2021
@tfranzel
Copy link
Owner

the sidecar is here: https://github.com/tfranzel/drf-spectacular-sidecar

convenience methods and doc added with aeda969. not relying on CDNs is now a lot easier.

@pombredanne
Copy link
Author

@tfranzel Thank you!

pombredanne added a commit to aboutcode-org/vulnerablecode that referenced this issue Oct 28, 2022
This will help generate an Open API documentation now that we do not
have CDN issues anymore with:
tfranzel/drf-spectacular#389

Referenced-by: #454
Thanks-you-to: T. Franzel @tfranzel
Signed-off-by: Philippe Ombredanne <[email protected]>
TG1999 pushed a commit to aboutcode-org/vulnerablecode that referenced this issue Nov 1, 2022
This will help generate an Open API documentation now that we do not
have CDN issues anymore with:
tfranzel/drf-spectacular#389

Referenced-by: #454
Thanks-you-to: T. Franzel @tfranzel
Signed-off-by: Philippe Ombredanne <[email protected]>
TG1999 pushed a commit to TG1999/vulnerablecode that referenced this issue Nov 4, 2022
This will help generate an Open API documentation now that we do not
have CDN issues anymore with:
tfranzel/drf-spectacular#389

Referenced-by: aboutcode-org#454
Thanks-you-to: T. Franzel @tfranzel
Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne added a commit to aboutcode-org/vulnerablecode that referenced this issue Nov 8, 2022
This will help generate an Open API documentation now that we do not
have CDN issues anymore with:
tfranzel/drf-spectacular#389

Referenced-by: #454
Thanks-you-to: T. Franzel @tfranzel
Signed-off-by: Philippe Ombredanne <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fix confirmation pending issue has been fixed and confirmation from issue reporter is pending
Projects
None yet
Development

No branches or pull requests

2 participants