The World Wide Web started out as a distributed hypertext system, where documents hosted on networked computers contain references to other documents, hosted on different networked computers. These documents can be retrieved using a browser, dedicated client software for viewing hypertext documents, and following hyperlinks embedded within the text of these documents. In order to make such a distributed hypertext system work, three fundamental agreements (standards) are necessary:
- Resource Identifiers URIs (originally called URLs) provide universally dereferenceable identifiers for resources on the Web.
- Transfer Protocol HTTP (Hypertext Transfer Protocol) is a universally supported transfer protocol that, in its bare essence, provides a simple mechanism to retrieve a resource across the network, and to submit form data from a browser to a Web server. HTTP is a request/response-based client-server protocol: The browser will send a request to a server that
- identifies the resource
- identifies the media types of representations that the client is willing to consume in response (e.g., plain text or HTML; GIF or PNG)
- Potentially is characterized as a form submission. The server responds with a resource representation that fulfills these constraints.
Today, cookies are used by practically every Web application but have the disadvantage that they are attached to every request, making them unfit for storing large amounts of data. Therefore, several recently introduced APIs offer client-side storage in the form of key-value pairs, an object database, or a virtual file system. These three major changes on top of the basic hypertext system have sparked the shift from one-way information exchange to a bidirectional read/write Web, also known as Web 2.0. This new stage in the evolution of the Web combines the technological advances with social aspects of actively participating users, resulting in dynamic applications, that actively improve as their number of users increases. Well-known examples are Wikipedia, Facebook, and the many Google services we use throughout the day. The social effect even intensified when people started carrying always-on, always-connected devices everywhere they go. Smartphones enable instant and continuous access to information, further stimulating location and context-aware social services.
Further development of the browser towards an application platform has resulted in a paradigm shift, where more responsibilities are pushed towards the client. The client component is no longer simply a view on the application running in the backend but has become the application, which interacts with a light, storage-centered backend application through rich, RESTful APIs. The technologies behind this paradigm shift are lightweight server-side technologies (e.g. NodeJS, Go), client-side libraries (e.g. JQuery, Bootstrap), and client-side templating frameworks (e.g. AngularJS, Ember.js). Additionally, browsers offer numerous useful features to Web applications, such as access to client-side storage facilities, access to information about the device and its sensors, and numerous communication mechanisms. This “application” of the Web is further stimulated by the rise of mobile devices, with their restricted operating systems and vendor-controlled application stores. Not only is the majority of applications offered in today’s application stores based on Web technology, but recent standardization efforts provide the necessary APIs to build Web applications that can interact with the underlying device, making them indistinguishable from native applications.
The Web has known several evolutionary steps, which have transformed the static server-side content into dynamic server-side applications and have transformed dull page-viewing browsers into execution platforms running highly dynamic and powerful Web applications. We observe a similar trend in the evolution of Web security, resulting in a shift from server-side to client-side Web security.