The Zoom localhost flaw was really a CORS misunderstanding

Plenty of web developers fundamentally misread how CORS works, and the 2019 Zoom vulnerability is a textbook case. Zoom ran a local web server on localhost:19421 that its website talked to in order to launch the native client. Rather than make a normal AJAX call, the page loaded an image from that server and read the response out of the image’s dimensions — a hack built specifically to dodge the same-origin policy. The premise was wrong: browsers like Chrome and Firefox do honor CORS for localhost servers, which is exactly why a Create React App frontend on one port can call an API on another. Zoom didn’t need the workaround; it needed to set the right headers.

By routing around CORS entirely, Zoom handed every site on the internet — not just zoom.us — the ability to poke its local server and trigger native-client behavior, including spinning up a meeting that switched on the user’s camera and microphone. The fix was mundane: have the localhost server expose a real REST API, return an Access-Control-Allow-Origin header scoped to https://zoom.us, and add a Content Security Policy that blocks framing so other pages can’t silently launch meetings. CORS exists to grant this kind of privileged cross-origin access safely; bypassing it threw that protection away.

The author’s broader point is that this isn’t a Zoom-specific lapse. Other vendors shipped the same bug, and insecure CORS advice — including permissive Express snippets that wreck an app’s security if copied verbatim — is everywhere on Stack Overflow. Developers reaching for whatever makes the request succeed will happily disable the same-origin policy without grasping the consequences. Whether the CORS API is simply too confusing or the industry just needs better education around CORS and CSP is left open, but the status quo clearly isn’t working.