New and Upcoming Security Features
You will soon find out that there is little rhyme and reason to how all the new browser features mesh, but we still need to organize the discussion in some way. Perhaps the best approach is to look at their intended purposes and begin with all the mechanisms created specifically to tweak the Web’s security model for a well-defined gain.
Related Search Term(s): The Tangled Web: A Guide to Securing Modern Web Applications
The dream of inventing a brand-new browser security model is strong within the community, but it is always followed by the realization that it would require rebuilding the entire Web. Therefore, much of the practical work focuses on more humble extensions to the existing approach, necessarily increasing the complexity of the security-critical sections of the browser codebase. This complexity is unwelcome, but its proponents invariably see it as justified, whether because they aim to mitigate a class of vulnerabilities, build a stopgap for some other hard problem that nobody wants to tackle right now, or simply enable new types of applications to be built in the future.
All these benefits usually trump the vague risk.
Security Model Extension Frameworks
Some of the most successful security enhancements proposed in the past few years boil down to adding flexibility to the original constraints imposed by the same-origin policy and its friends. For example, one formerly experimental proposal that has now crossed into the mainstream is the postMessage(...) API for communicating across origins, discussed in Chapter 9. Surprisingly, the act of relaxing SOP checks in certain carefully chosen scenarios is more intuitive and less likely to cause problems than locking the policy down. So, to begin on a lighter note, we’ll focus on this class of frameworks first.
Under the original constraints of the same-origin policy, scripts associated with one origin have no clean and secure way to communicate with client-side scripts executing in any other origin and no safe way to retrieve potentially useful data from a willing third-party server.
Web developers have long complained about these constraints, and in recent years, browser vendors have begun to listen to their demands. As you recall, the more pressing task of arranging client-side communications between scripts was solved with postMessage(...). The client-to-server scenario was found to be less urgent and still awaits a canonical solution, but there has been some progress to report.
The most successful attempt to create a method for retrieving documents from non-same-origin servers began in 2005. Under the auspices of W3C, several developers working on VoiceXML, an obscure document format for building Interactive Voice Response (IVR) systems, drafted a proposal for Cross-Origin Resource Sharing (CORS). Between 2007 and 2009, their awkward, XML-based design gradually morphed into a much simpler and more widely useful scheme, which relied on HTTP header–level signaling to communicate consent to cross-origin content retrieval using a natural extension of the XMLHttpRequest API.
CORS Request Types
As specified today, CORS relies on differentiating between two types of calls to the XMLHttpRequest API. When the site attempts to load a cross-origin document through the API, the browser first needs to distinguish between simple requests, where the resulting HTTP traffic is deemed close enough to what can be generated through other, existing methods of navigation, and non-simple requests, which encompass everything else. The operation of these two classes of requests vary significantly, as we’ll see.
The current specification says that simple requests must have a method of GET, POST, or HEAD. Additionally, if any custom headers are specified by the caller, they must belong to the following set:
Today, browsers that support CORS simply do not allow methods other than GET, POST, and HEAD. At the same time, they ignore the recommended whitelist of headers, unconditionally demoting any requests with custom header values to non-simple status. The implementation in WebKit also considers any payload-bearing requests to be non-simple. (It is not clear whether this is an intentional design decision or a bug.)