Rethinking Web Security: Why CORS and JavaScript are Broken — And How We Could Fix It
Introduction: The Hidden Flaws of Web Security
In today’s world, where almost every aspect of our lives is digitized, the security of the web has become more important than ever. But despite the layers of security mechanisms built into modern browsers, such as CORS (Cross-Origin Resource Sharing) and the Same-Origin Policy (SOP), the web remains riddled with vulnerabilities that attackers can exploit. At the heart of this issue lies a flawed development cycle and a misunderstood security model, which evolved in a way that leaves both developers and users vulnerable.
What if the way we think about web security has been wrong all along? What if, instead of patching up inherent problems in JavaScript and CORS, we had restructured the web itself from the ground up, putting security first? In this article, we’ll explore the core weaknesses of the web’s current security model, how browsers obscure critical details from developers, and how an entirely different approach to handling sensitive data might lead to a safer, more robust web.
The Problem with CORS and "Magical" Preflight Requests
Let’s start with CORS, the mechanism designed to prevent unauthorized cross-origin requests from being made to different domains. CORS is meant to enforce the Same-Origin Policy, ensuring that web pages can only make requests to the same domain unless explicitly allowed by the server.
In theory, CORS seems like a great idea. But the implementation is deeply flawed. One of the major misunderstandings lies in the preflight request — the key piece of the negotiation process between the browser and the server that determines whether a request can proceed.
Many developers are led to believe that CORS happens “ahead of time,” a term thrown around in documentation that creates confusion. The truth is that preflight requests are essential for establishing whether cross-origin requests are permitted. However, browsers often hide the first preflight request from developer tools, leading to misconceptions about how the browser is handling CORS negotiation. Developers might never see the "successful preflight," leading them to assume the browser "magically" knew what was allowed, which couldn't be further from the truth.
In essence, CORS isn't broken because it's inherently bad. It's broken because it was built on top of a flawed system that tries to patch over fundamental issues with cross-origin communication, rather than solving the core problem: the way client-side JavaScript interacts with sensitive data.
Why the Evolution of the Web Failed Security
The web’s security challenges, including the problems with CORS, stem from the fact that web technologies were not originally designed with today’s complex security needs in mind. The Same-Origin Policy and CORS are attempts to retrofit security onto an inherently open system where client-side JavaScript has unrestricted access to critical data.
The reliance on cookies for session management, the use of global variables in JavaScript, and the exposure of sensitive data to client-side code all contribute to a security model that is fundamentally flawed. Attackers can exploit XSS (cross-site scripting) vulnerabilities to inject malicious JavaScript, hijacking cookies, and stealing session tokens. Despite mechanisms like CSP (Content Security Policy), SameSite cookies, and secure headers, many of these issues persist due to the inherent openness of JavaScript and the lack of centralized control over sensitive data.
But what if the web had taken a different route? What if the browser — instead of JavaScript — handled all sensitive data operations, and developers had no direct access to session tokens or critical information? This could have changed everything.
Rethinking Web Security: A New Approach
Let’s imagine an alternate reality where the web evolved differently — one in which sensitive data was never exposed to JavaScript, and all data operations were controlled by the browser.
1. No More Cookies
Cookies have long been the default method for managing sessions and authentication. But cookies come with many vulnerabilities: they are automatically sent with every request, are often visible to JavaScript, and are prime targets for CSRF (Cross-Site Request Forgery) attacks. In this new model, we eliminate cookies entirely.
Instead of cookies, the browser securely stores session information and authentication tokens, preventing them from ever being exposed to JavaScript. The browser would act as the gatekeeper, providing encrypted tokens that can only be decrypted by the server — with no direct access granted to the client-side application.
2. Eliminate Global Variables in JavaScript
Global variables have always been a point of contention in JavaScript development. They’re convenient but dangerous. Attackers can easily access global variables if they manage to inject malicious scripts, especially in the case of XSS attacks.
By eliminating global variables entirely and forcing all sensitive data access through browser-controlled APIs, we can minimize the attack surface. JavaScript would no longer have free reign over sensitive information. Instead, developers would interact with tokens or references to data, while the actual data stays safely stored inside the browser’s secure vault.
3. Data Handling via Browser API
In the proposed model, sensitive data is managed entirely by the browser. Developers wouldn’t be able to send raw data through JavaScript. Instead, they would reference the data by name, and the browser would manage the encryption and transmission automatically.
When sending sensitive data to a server, the browser would fetch an encryption key from the server, encrypt the data internally, and send the request securely — without ever exposing the plaintext data to JavaScript. When retrieving sensitive data from the server, the browser would store the data securely and return only a name or token for use in the application.
4. Partial Data Exposure and Contextual Security
When sensitive data must be exposed to JavaScript (for example, for rendering purposes), the browser could enforce partial data exposure. Each JavaScript function would have a unique hash or identity that the browser verifies before allowing access to specific parts of sensitive data. This way, only the parts of the data that are necessary for that specific function would be exposed, and only to trusted code. This would prevent attackers from gaining access to entire datasets.
By managing sensitive data at the browser level rather than the JavaScript level, we can ensure that data is always secure — regardless of what scripts are running on the page.
Why We Didn’t Take This Path
While the model we propose would greatly improve web security, it’s easy to see why this path wasn’t taken. Implementing these features would introduce significant complexity and could slow down web development. Browsers would need to manage a great deal of overhead to handle encryption, decryption, and secure data storage internally. Furthermore, breaking backward compatibility with billions of websites would be a monumental task.
Another reason is developer simplicity. The current model — while vulnerable — is easy for developers to understand and work with. Moving all sensitive data handling to the browser would create a steeper learning curve and could frustrate developers who are used to the flexibility of client-side JavaScript.
The Consequences of Our Development Path: Are We Doomed?
The current web security model is a patchwork of CORS, SOP, and JavaScript hacks. It leaves too much responsibility in the hands of client-side code, exposing sensitive data and opening the door to attacks like XSS and CSRF. While solutions like Content Security Policy (CSP) and SameSite cookies have helped, they are just band-aids on a broken system.
The model we've discussed, where sensitive data is tightly controlled by the browser, would be far more secure. But because we didn’t take this route, we’re left with a web full of vulnerabilities that will likely persist for years to come.
Conclusion: Can We Fix Web Security?
The web’s development cycle has undeniably led us down a path full of security pitfalls. CORS, SOP, and JavaScript’s open architecture are all symptoms of a system that wasn’t built with today’s security needs in mind. While it’s unlikely that we’ll be able to move to a fully browser-controlled security model like the one we’ve outlined, it’s important to acknowledge the flaws in the current system and explore ways to mitigate them.
By advocating for stronger browser-based controls over sensitive data, better security tools, and less reliance on client-side JavaScript, we might be able to make incremental improvements. The question remains: will the web continue to evolve in a secure direction, or will we remain stuck in a broken cycle?