Defending against Malicious Activity in an Unmodified Browser

Dan Boneh

Browser Attack

Website publishers can derive enormous performance benefits and cost savings by directing traffic to their sites through content distribution networks (CDNs). However, publishers using CDNs today must trust their CDN’s infrastructure security. A compromised CDN can let hackers modify JavaScript, CSS, and other assets en route to end users. A CDN that violates this trust could inject ads into websites, downsample media to save bandwidth or, worse, inject code to steal user secrets it could not otherwise access.

Today we present Stickler, a theoretical platform for protecting the integrity of a web application from a faulty CDN.

Benefits and Risks of CDNs

A website publisher may choose to employ a CDN for a variety of reasons:

  • CDNs can serve the bulk of a site’s assets from a long lived cache, dramatically reducing load on the publisher’s servers.
  • CDNs maintain edge servers around the world, so they can service cached content to clients with relatively low end-to-end latency.
  • CDNs allow publishers to maintain availability in the face of a rapid spike in traffic (i.e., a “flash crowd”)

Often, CDN-cached assets are served from a CDN controlled domain (e.g. However, publishers may choose to have the CDN cache content on a particular subdomain (e.g., Alternatively, a publisher may point the DNS records for her site to the CDN’s servers allowing the CDN to serve as a front-end proxy for all requests. Either way, once the website has directed the end user to retrieve content from a CDN, it is difficult for a user’s browser to verify the authenticity of that content.

Threat Model and Security Goals

Stickler is a model to secure websites and protect them against attacks in case a CDN is compromised. With Stickler, publishers can realize the scalability and availability benefits of a CDN without the integrity risks (and thus confidentiality risks) of serving assets from a third-party server.

Stickler separates authenticity of the connection from authenticity of the content by signing content directly with a private key the site owner never has to share with the CDN. In fact, if the site consists entirely of static content, even the publisher’s own web servers need not hold a copy of the publisher’s private signing key. End users can verify all site content independently of how they receive the pre-signed content, whether directly from the web site’s servers, through a CDN provider, or even via a peer-to-peer CDN like CoralCDN. Crucially, Stickler achieves these guarantees without requiring modifications to the browser. Stickler is an effective short-term solution for browsers that will eventually support W3C Subresource Integrity mechanism (SRI) and is a useful long-term solution for browsers and platforms (e.g., old smartphones) that may never support SRI.

Stickler does have some limitations: it requires publishers to sign every static asset, imposes some performance penalty on the user, and prevents the CDN from optimizing assets to their full potential.

A fully Stickler-protected demonstration website is

Performance Evaluation

As stated earlier, one of the limitations of Stickler is the inherent performance penalty it poses. While the performance with and without Stickler on Chrome is comparable, Stickler imposes roughly a 5x performance penalty when using Firefox when the number of assets on the page is large (see Figure 3). Whether or not this overhead is acceptable will depend on the particular security requirements of the application, but we expect that for especially sensitive sites (e.g., a health data site), publishers will be willing to pay a performance cost for a security benefit.

Compares the time it takes to render a Stickler-protected page
Fig: compares the time it takes to render a Stickler-protected page with the time it takes to load an unprotected static HTML page as the number of assets on the page varies.


Stickler is a framework for protecting the integrity of a web application from a faulty CDN. Stickler uses a JavaScript-based bootloader delivered directly from the publisher’s domain to verify the provenance of site assets delivered via a minimally trusted CDN. Crucially, Stickler does not require browser extensions or modifications and it is compatible with popular web publishing tools and techniques. Our implementation and evaluation of Stickler demonstrate its practicality and performance. With this work, we show that website publishers can reap the manifold performance and cost benefits of using a CDN without having to put unnecessary trust in the CDN.

Check out the recently published technical paper for for a more in-depth discussion. Stickler is joint work with Amit Levy and Henry Corrigan-Gibbs and was presented at the 2015 IEEE Web 2.0 Security and Privacy workshop.

By Dan Boneh, Professor of Computer Science and Co-director of the Security Lab at Stanford University

Leave a Reply

Your email address will not be published. Required fields are marked *