An important trend in client-side Web security is the rise of server-driven client-side security policies. These policies have been developed alongside the line of research on autonomous client-side mitigation techniques, both in research, as illustrated by the WebSand project, as in practice, as illustrated by examples such as Content Security Policy. These server-driven security policies are delivered by the server, where the desired security properties and underlying application structure are known and are enforced by the browser, the most optimal location for enforcing client-side security policies.
Server-driven client-side security policies have emerged from a constantly evolving security process, which started with generic browser security policies, such as the Same-Origin Policy, which were applied to all applications, without exceptions or customizations. As the server-side processing component of Web applications became more advanced, Web security mechanisms and countermeasures against concrete attacks were to be implemented at the server-side. Well-known examples are token-based approaches against CSRF attacks, or input and output sanitization against injection attacks. While these security mechanisms initially required a significant amount of effort from the developer, the developer community quickly caught up, offering easy-to-use libraries and out-of-the-box support in popular development frameworks. Unfortunately, as we witness up until today, merely offering support for the appropriate security technology is not sufficient to secure the Web. Many developers are not aware of all the security technology they need to incorporate, and legacy applications are often not updated to include the optimal security solutions, due to various reasons, such as technical difficulties or a lack of interest.
Taking into account that most attacks do in fact originate from server-side vulnerabilities, such as a failure to properly sanitize input and output, this seems an unfair evaluation. These countermeasures are intended to give a security-conscious Web developer an additional tool to squash attackers that manage to evade the server-side defenses, as well as to add a layer of protection to a legacy application, which can not easily be modified to incorporate the appropriate defenses. The seemingly secondary role of server-driven client-side mitigation techniques should not be mistaken for a sign of inutility, as they are essential for deploying an in-depth defense strategy. Applying multi-layered defense attributes to well-established security principles, and effectively helps stop an attacker who has managed to circumvent alternative protection mechanisms.