-
-
Notifications
You must be signed in to change notification settings - Fork 553
disable "/v3/api-docs", and "/swagger-ui.html" by default and upgrade to Scalar 0.2.1 #3090
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
disable "/v3/api-docs", and "/swagger-ui.html" by default and upgrade to Scalar 0.2.1 #3090
Conversation
|
i have merged with the latest version. |
|
Making it disabled by default would be better. You could introduce a new property like From previous experience, I've found that people typically disable SpringDoc via You might say this is a noob mistake, but in reality, the mistake is made by principal-level developers, and it passes both internal and external penetration testing. No one catches it for months in production, until a curious junior developer (me at one of my previous companies) discovers it by accident. There may still be other systems/companies where this issue hasn't been discovered yet, so it's better to disable it by default and ensure users familiarize themselves with your library before enabling it. Note that I sent the same concern to Scalar via email, and they accepted it: scalar/scalar#6781 (Of course, I also sent the same concern to SpringDoc via email) I agree with you that it may seem overkill, but when you look at it from the user's perspective, it makes sense. Also, in 2024, the CVE board updated the CNA rules, including the following:
So what do you think? Thank you for your effort in providing the Spring ecosystem with this library which makes our lives easier. |
|
This change seems like a breaking change. Does not SpringDoc use semantic versioning? |
|
@zakaria-shahen FYI, this PR does not actually disable OpenAPI generation, and SwaggerUI rendering My setup: It looks like instead of changing these properties values like this PR did, you should be changing the In other words, it looks like this PR did not do what it was saying. |
|
You're right, this PR does two things:
However, @bnasslahsen merged it but only accepted the Scalar upgrade, and Unfortunately then reverted the change that I made to disable SpringDoc and Scalar by default (as per his comment see #3090 (comment)) So, unfortunately yes Scalar (within springdoc only) and Springdoc are still enabled by default *Because Scalar is disabled by default in after this version. (see scalar/scalar#6781)
|
|
So this PR (after the additional changes) results only in these two log messages if I am not mistaken: I think it's a good improvement, even though there are many people who ignore warnings. |
|
Yes, you'll see two logs in your case. However, if you add either But I hope @bnasslahsen changes his mind and makes it disabled by default, There are similar cases where maintainers have done that, like the Spring team with Spring Actuator properties (after the Volkswagen issue and Spring Boot Actuator misconfiguration) Really, unready docs exposed to the public internet without review can lead to bigger issues like reverse engineering, knowledge/data leak etc.
|
|
Yes, probably. But if it stays as it is, it should at least be the case that setting the properties to |
Disable SpringDoc by default to maintain alignment with Scalar (scalar/scalar#6781) and ensure that the default configuration follows secure-by-default principles.