Why developers still misunderstand CORS — lessons from the Zoom localhost flaw

A 2019 essay by full-stack consultant Chris Foster, still circulating among developers, argues that too many web developers do not understand how Cross-Origin Resource Sharing (CORS) works — and that the misunderstanding has real security consequences. His case study is the localhost flaw in the Zoom desktop client disclosed by security researcher Jonathan Leitschuh in July 2019.

The Zoom localhost loophole

Zoom's client installed a web server on the machine listening at http://localhost:19421. When a user opened a Zoom link, the zoom.us website sent a request to that local server instructing it to launch the native application. Instead of a regular AJAX request, the page loaded an image from the local web server, and the image's dimensions encoded the server's status or error code. In his write-up, Leitschuh suggested this was done to bypass CORS, because, as he put it, browsers explicitly ignore CORS policy for servers running on localhost.

Foster points out that this claim is wrong: Chrome does respect CORS headers for localhost web servers, and cross-origin requests against localhost are supported in all browsers — developers do it routinely when a Create React App front end runs on one port and its API on another. The image trick, he argues, means Zoom either did not understand CORS or chose to work around it, and the workaround was costly: not only zoom.us could trigger operations in the native client and read the response, but so could every other website on the internet.

What a secure implementation would look like

The local web server should expose a REST API and send an Access-Control-Allow-Origin header with the value https://zoom.us, so that only JavaScript running on the zoom.us domain can talk to it. On top of that, zoom.us should send a Content Security Policy header that blocks rendering inside an iframe, so pages cannot silently open meetings in the background. That still leaves the fact that any page can redirect a browser to a zoom.us link for an unexpected meeting — which Foster classifies as a user-experience decision rather than a software vulnerability, and one he disagrees with: software must be predictable, and clicking a link should not make your camera and microphone available to strangers. He cites Google Meet's in-app popup as the better pattern.

Why the confusion persists

Foster notes the problem is not limited to Zoom: vendors have been caught with the same class of vulnerability, and Stack Overflow is full of CORS questions, often alongside advice that recommends insecure defaults — for example an Express snippet published by enable-cors.org that would make an application vulnerable if copied verbatim. Possible technical excuses do not hold up either: Firefox may block some requests from secure to non-secure origins, but it supports localhost, and native apps can generate a self-signed certificate or ship a browser extension. Bypassing the same-origin policy may get code working, he concludes, but it creates problems later — and it remains unclear whether CORS is simply too complex an API or whether developer education needs to catch up.