Update the OpenAPI Specification[🚀]

[ailton07]

🚀 Feature request

Description

Once the OWASP API Security Top 10 2019 items were added to OWASP Juice Shop challenge categories (juice-shop/pwning-juice-shop@7abe69d), I think would be great if the Juice Shop OAS were updated.

Solution ideas

Currently, the main tool to create and update OASs is Swagger Editor , despite there extensions to several code editors (ie. Eclipse, VS Code, and Atom).

[github-actions]

Thanks a lot for opening your first issue with us! 🧡 We'll get back to you shortly! ⏳ If it was a Support Request, please consider asking on the community chat next time! 💬

[ailton07]

I verified just now that Juice Shop OAS describe only 'API for our enterprise customers'. So, I suggest the creation of a new OAS to describe the 'private' APIs.

[bkimminich]

The existing B2B API is housing two hacking challenges. There is no functional need to add any other similar API descriptions from my point of view. What kind of update are you suggesting exactly? The swagger.yml is already using openapi 3.0.0 format.

[ailton07]

Using an API contract, like OAS, allows you to use newer solutions for API protection (thus new vulnerabilities), and with that, new challenges. For example, when we know what kind of query parameter is expected, it is easier to mitigate injection attacks and detect parameter tampering.
Create and maintain documentation of private APIs is becoming a standard due to security questions, and I think it would be interesting JS replicate this pattern. Therefore, I'm suggesting the creation of an OAS that describes all Rest APIs in Juice Shop.
However, right now, I agree that there is no functional need to the current Juice Shop case of use. But developing an API specification allows the creation of newer challenges in the future.

[bkimminich]

Okay, but having this for the generated /api and hand-crafted /rest APIs would make current challenges a lot easier, e.g. as it would spoiler that some allow POST/PUT/DELETE where they clearly shouldn't or are missing access control alltogether etc.

The "storyline" behind not having this, is kind of "the developers were too lazy to document the API or create a contract in front of it. Nobody will ever use that API directly anyway, it's only there for our own frontend."

[ailton07]

Indeed, having an Open API specification would make current challenges a lot easier. Actually, I hadn't thought about that.
Considering all these factors, I get it the absence of 'complete' API documentation. However, if you consider that it is interesting to add that doc in the further, I would be happy to contribute.

[github-actions]

This thread has been automatically locked because it has not had recent activity after it was closed. 🔒 Please open a new issue for regressions or related bugs.