Security on the Web

John Kemp

4th February 2011


This document summarizes the history, and current state of some of the security features of the Web, as well as some of the effects on overall Web security of (some of) these features.


The Web (initially physically implemented as an HTTP server, a Web browser and the HTTP protocol) was born with a particular set of properties in mind. Initially, security was not one of these properties. As the Web grew, and its components were extended to support new models and ideas, it became necessary to consider the security properties of the Web, however it was difficult to either reliably deploy or enforce security properties broadly because of the massive installed-based of Web agent software, so incremental "patches" were applied, leading to an arms race between those making the patches, and those creating the attacks (particularly in the area of the "same-origin policy").


HTTP - the "stateless" protocol

Requirements of the Web (largely from [1])

HTTP 0.9 ([2])

HTTP 1.0 ([3])

Origin cookies are first baked

Netscape Navigator first implemented support for cookies in its version 2.0 browser, dating from 1996. Cookies offered a mechanism to allow a server to store per-client state, and have the client supply a (server-assigned) pointer to its state, automatically (via the client implementation) when sending any request to the cookie-specified domain and URL path. Many sites used this facility to identify a user session with the site, and then stored per-user/session data (such as a shopping cart) related to the cookie identifier.

Cookies became successful because they were more reliable session indicators than competing mechanisms (such as putting session state in the URI or body of an HTTP request, which require that users don't accidentally drop the session part of the URI, for example)

In order to ensure that a cookie was sent only to the originating domain, the browser needed to be able to determine the domain associated with a document - and thus, the "origin" was born - scheme, host and port defining a unique origin. The same-origin policy states that a document from one unique origin may only load resources from the origin from which the document was loaded. In particular this applies to XMLHttpRequest calls made from within a document. Images, CSS and dynamically-loaded scripts are not subject to same-origin policy.

AJAX: The rise of the cross-domain request [5]

In 1999, Microsoft released the second version of its MSXML library, which provided access, via ActiveX, to an API for making a direct HTTP request to a web server. Other browsers followed, with Mozilla releasing a Javascript XMLHttpRequest (XHR) API in its Gecko engine, and later by other browser vendors releasing similar APIs.

The "XHR" API was later standardized by W3C [6] and Javascript-based frameworks have abstracted the API and popularized its usage by making it even easier to make HTTP requests from within Web documents.

Various mechanisms are used to circumvent the same-origin policy enforced by XHR, including JSONP [7] and allow cross-domain calls from Web applications.

The rise of Javascript and Web applications

Web browsers have contained a Javascript execution environment since Netscape Navigator 2.0. Initially, Javascript was denigrated by "serious" programmers, but thanks to the popularity of AJAX, has become one of the most popular software development languages in use today.

Exposing APIs from a Web browser, via Javascript and the DOM, allows a developer to manipulate client resources in a much more fundamental way than simply rendering and viewing a document.

There are several security vulnerabilities related to the use of Javascript in browser environments (see [9] for examples)

Security-related issues of Web architecture

Desirable security properties of the Web?

Some current Web security-related standards work


Security on the Web, John Kemp, 4th February 2011