Zoom got around the CORS restriction by requesting an _image_ which is not subject to CORS. So there are some limitations of what can be done and how you can access things. But you could certainly use this technique to do some simple IP/port scanning on a user's local network.
Just to be clear: There's no need to "get around" CORS in the Zoom case. Browsers simply allow cross-domain GET and POST requests. Period.
CORS mediates the ability of JavaScript running in one origin to _read_ responses from another origin. If Zoom wanted JavaScript on any site to read data from the local installation, their local web server would need only return appropriate CORS headers. This was not necessary for the use case of joining a meeting.
This is my understanding too, but judging from the comments in this thread, either a lot of developers aren't clear on the difference between CORS and CSRF or else they're referring to aspects of CORS I'm not familiar with.
It is true. But then, it's an intentional bad design choice by whomever wrote the server. If your server does actions on a GET, or accepts POSTs without a CSRF token protection, that's not the fault of the browser, but a well known behaviour.
"simple requests" are exempts of CORS. Images is one way, but any GET request without special headers and with a specific subset of content types will quality and are exempts from CORS. Certain simple POSTs too if my memory's not too bad.
