I realize that this has a lot of dependencies, and pulls in the react framework. I have been trying to find an alternative that is based on Vue.js, since that is what we are using anyway. The best I could find is https://github.com/koumoul-dev/vue-openapi, which seems fairly lightweight. I haven't tired it, though. And while it doesn't seem completely dead, it doesn't have a lot of activity or contributors either.

Toolhub uses https://rapidocweb.com/, which seems to be quite lightweight:

"dependencies": {
  "@apitools/openapi-parser": "0.0.30",
  "base64-arraybuffer": "^1.0.2",
  "buffer": "^6.0.3",
  "lit": "^2.6.1",
  "marked": "^4.2.12",
  "prismjs": "^1.29.0",
  "xml-but-prettier": "^1.0.1"
},

Just wanted to update that the review will be posted by the end of next week (March 31) at the latest. And as far as https://github.com/koumoul-dev/vue-openapi goes, while it has less dependencies, the lack of activity/contributors puts it on board with swagger-ui. We would prefer an actively maintained project with more eyes on it. I'll take a look at https://rapidocweb.com/ as well, thanks for posting!

Re rapiddocweb: while it seems to be actively maintained, it looks like a one-person project: https://github.com/rapi-doc/RapiDoc/graphs/contributors

Security Review Summary - T325558 - 2023-03-31

Overall, the current vendor code under consideration has an overall risk rating of: medium.

The swagger-ui project has a healthy amount of maintainers along with several bots that keep dependencies updated and cut releases on a regular schedule. They also have a clear policy for reporting security issues. They have a current open security issue that is mitigated as long as we use version 4.1.3 swagger-ui or above. Along with that, there's also a security policy that could be more detailed, but is a start in terms of a security policy. There are some minor vulnerabilities in the project, but since they are current with the releases and transparent with any security issues that do occur. However, the presence of webpack is considered a lower quality dependency by the application security team and therefore this project will receive a medium rating.

The scorecard rating of 5.8/10 is lower that desired, however several of the scorecard issues are listed in the vulnerabilities below and the others are not high priority. The same goes for semgrep which found overlapping issues with the listed vulnerabilities. Both reports can be attached for completeness if desired.

The other projects mentioned such as https://github.com/koumoul-dev/vue-openapi and https://github.com/rapi-doc/RapiDoc/graphs/contributors are possible contenders but those issues have been mentioned. If the team decides they want to move forward with either, we can add a request to the application security reviews to take a more in depth at those projects.

Swagger UI

General Security Information

Vulnerable Packages

Outdated Packages
As reported via npm outdated:
(no explicit vulnerabilities reported, simply noting for completeness' sake.)

Static Analysis Findings

1. lockfile-lint no issues detected low risk
2. gitleaks returned no results. low risk
3. scan scan:latest returned no results, outside of the previously-mentioned vulnerable packages. low risk
4. semgrep 0.120.0 was run with 983 rules on 304 files: 19 findings low risk
5. scorecard returned an aggregate score of 5.8 / 10 medium, see results here

@Mstyles Thank you for the detailed analysis!

Can you halp me assess the concrete risk posed by the "high" issues? The following questions come to mind looking at your analysis:

• Would yopu agree that the ReDoS vulerabilities are not an issue because all the code is run client side?
• Am I correct in assuming that mitigation by "npm audit fix" means we can't use the minified bundle?
• If I understand correctly, oauth-server is used when swaggerui is configured to allow authenticated requests to the API. Would you agree that the risk is mitigated by not enabling that feature?

In T325558#8749341, @daniel wrote:

@Mstyles Thank you for the detailed analysis!

Can you halp me assess the concrete risk posed by the "high" issues? The following questions come to mind looking at your analysis:

• Would yopu agree that the ReDoS vulerabilities are not an issue because all the code is run client side?

The risk is minimized, but still present as attackers can find ways to exploit vulnerable code.

• Am I correct in assuming that mitigation by "npm audit fix" means we can't use the minified bundle?

You can still use the minified bundle. The npm audit fix is how the swagger-ui project maintainers would fix the issue. We can't guarantee that they will update the versions in a timely manner. That's a part of the risk that needs to be accepted by a manager/director and entered in the risk registry.

• If I understand correctly, oauth-server is used when swaggerui is configured to allow authenticated requests to the API. Would you agree that the risk is mitigated by not enabling that feature?

If we're not using the oauth-server and it's possible to disable it, then I think we should definitely do that. The risk of this project still remains at medium though mainly due to the webpack dependency.

The webpack vulnerability is pretty silly. It is basically - if an attacker can modify your source code, then they can run arbitrary code.

One presumes that the platform team does not intend to allow malicious people to have commit access, and that if a malicious person was able to deploy code they would have much juicier things to target.

In T325558#8760631, @Bawolff wrote:

The webpack vulnerability is pretty silly. It is basically - if an attacker can modify your source code, then they can run arbitrary code.

One presumes that the platform team does not intend to allow malicious people to have commit access, and that if a malicious person was able to deploy code they would have much juicier things to target.

If I'm reading the vuln description correctly, this part:

"An attacker who controls a property of an untrusted object can obtain access to the real global object."

would imply simpler object injection style attacks via JS' object array access. I'd agree that this is likely difficult to exploit in the wild, unless there are some extremely terrible code patterns in place, but it's a simpler attack than other varieties of code injection/RCE.

@MNadrofsky you have been entered into the risk register as the owner of medium risk for this project. Please let us know if you have any questions.

Thank you!