Developers don't understand CORS (2019)
This 2019 article brilliantly dissects how a widespread misunderstanding of Cross-Origin Resource Sharing (CORS) can lead to significant security vulnerabilities, using the infamous Zoom zero-day as a prime example. The author argues that many developers bypass CORS due to confusion, creating avoidable risks rather than leveraging its security benefits. On Hacker News, the discussion resonated deeply, with many developers openly admitting their struggles with CORS and debating its complexity, error messages, and true security threat model.
The Lowdown
The article posits that a significant number of web developers, regardless of experience, lack a fundamental understanding of how Cross-Origin Resource Sharing (CORS) truly functions. This knowledge gap often leads to insecure workarounds, rather than proper implementation, opening doors to vulnerabilities.
- The author highlights a 2019 Zoom vulnerability where the application used an 'image hack' to bypass CORS when interacting with a localhost web server. This allowed any website to trigger actions in the native Zoom client.
- Contrary to Zoom's likely assumption, browsers do respect CORS for localhost, meaning a secure implementation using
Access-Control-Allow-Origincould have prevented the vulnerability. - The article criticizes Zoom's approach as a classic example of not understanding CORS, leading them to build an insecure workaround that exposed user webcams.
- A secure implementation would involve the localhost server explicitly allowing requests only from
https://zoom.usand potentially using a Content Security Policy (CSP). - The author notes that this isn't an isolated incident, citing widespread confusion visible on platforms like Stack Overflow and similar vulnerabilities in other software.
- The piece concludes by questioning whether CORS is inherently too complex or if there's a critical need for better developer education on web security mechanisms like CORS and CSP.
Ultimately, the article serves as a stark reminder that developers' desire to simply 'make code work' can, without a thorough understanding of underlying security principles, inadvertently introduce severe risks.
The Gossip
CORS Conundrums
A dominant theme revolved around developers' shared frustration and admission of not fully grasping CORS. Many agreed it's a difficult concept, citing cryptic error messages, its 'inverted' security model compared to traditional server-side security, and its patchwork evolution within web standards. Some highlighted the intentional obscurity of browser error messages as a contributing factor to debugging woes.
Threat Model Muddle
Commenters grappled with the actual threat model CORS addresses. Some argued it's specifically for XSS and CSRF against actively logged-in human users, and that other attack vectors can easily bypass it. Others questioned its real-world utility, suggesting it 'does nothing useful today' or that its complexity leads to insecure 'allow all' configurations. There was also clarification that CORS primarily prevents JavaScript from *reading* cross-origin responses, not from *making* the requests, and that it helps services signal to browsers their CSRF resistance.
Bypassing Blunders
Several commenters acknowledged the common developer practice of implementing insecure CORS configurations, like using `*` for `Access-Control-Allow-Origin`, simply to get their applications to function. This was attributed to a lack of understanding, the perceived difficulty of CORS, and a focus on expediency over security. The Zoom example was seen as a high-profile manifestation of this tendency.