API step JS/TS unmatched access method leads to the Workbench UI; mishandled access methods

[crtag]

Having a single API endpoint defined as a "POST" handler and accessing it via "GET" results in the HTTP 200 and returned HTML for the Workbench.
Expected is an HTTP 405. Other access methods - PUT, PATCH, DELETE return 404, which is not quite right and should also return 405.

This can be handled by the infrastructure; however, this is inefficient from the maintenance/architectural point of view.
This also leads to unintended consequences when hosted behind NGINX, where a wrongly successful HTTP 200 will reveal the workbench. Would consider this a critical security issue.

[rohitg00]

Hey @crtag! 👋

Thanks for this issue - you've identified a genuine security issue here, and I appreciate you thinking through the NGINX deployment implications.

You're absolutely right about the main problem: GET requests on POST-only endpoints returning 200 with Workbench HTML is definitely a security risk. I'm creating an internal ticket to get this prioritized - the security implications with reverse proxy setups make this critical to address quickly.

Will update you on progress once I hear from the team. Thanks for the thorough analysis! 🛡️