Too many developers still misunderstand how CORS works, and Zoom’s recent localhost hack illustrates the gap. Zoom’s web client talks to a tiny HTTP server on http://localhost:19421 by loading an image file whose width and height encode status codes. That trick was meant to dodge CORS—but Chrome does enforce CORS headers even on localhost. Normal setups like Create React App routinely rely on Access-Control-Allow-Origin to permit cross-port calls during development. Zoom’s image hack exposed its native client to commands from any site, not just zoom.us, creating a serious vulnerability. A safer design would expose a RESTful API on localhost:19421 and send Access-Control-Allow-Origin: https://zoom.us so only scripts from zoom.us can talk to it. On top of that, zoom.us pages should use a Content Security Policy that disallows framing, preventing silent iframe-based launches. You’d still need to think through unexpected redirects to zoom.us meeting URLs, but that’s a deliberate UX choice rather than a security bug. Better yet, implementing an in-app confirmation prompt would keep behavior predictable—Google Meet’s approach prompts you before opening your camera and mic. This isn’t just a Zoom problem. I’ve seen junior and senior developers alike copy insecure CORS workarounds from Stack Overflow or default to permissive headers in Express apps. Some defend hacks by pointing to Firefox’s mixed-content rules, but Firefox also allows secure-to-localhost calls. Native clients can use self-signed certificates or browser extensions if they really need to bypass same-origin policy. Skipping proper origin checks invites exactly the kind of incident Zoom just faced. CORS and CSP exist to secure interactions between browsers and servers—especially when you’re running a local webserver with privileged access. Instead of inventing image-based hacks, developers should set correct CORS headers or choose alternative delivery mechanisms. Better education on these web standards would prevent the next headline-grabbing flaw.