Stickler: Defending Against Malicious CDNs in an Unmodified Browser

Website publishers can derive enormous performance benefits and cost savings by directing traffic to their sites through content distribution networks (CDNs). However, publishers who use CDNs today must trust their CDN not to modify the site’s JavaScript, CSS, images or other media en route to end users. A CDN that violates this trust could inject ads into websites, downsample media to save bandwidth or, worse, inject malicious JavaScript code to steal user secrets it could not otherwise access. We present Stickler, a system for website publishers that guarantees the end-to-end authenticity of content served to end users while simultaneously allowing publishers to reap the benefits of CDNs. Crucially, Stickler achieves these guarantees without requiring modifications to the browser.

💡 Research Summary

Stickler addresses a fundamental tension in modern web delivery: the desire to exploit the performance and cost advantages of Content Distribution Networks (CDNs) while needing to guarantee that the assets delivered to end‑users have not been tampered with. The paper begins by outlining realistic threats posed by a malicious or compromised CDN—ad injection, media down‑sampling, and, most critically, the insertion of malicious JavaScript that can harvest credentials or perform drive‑by attacks. Existing mitigations such as HTTPS protect the transport channel but do not prevent a CDN from altering cached objects, and Subresource Integrity (SRI) requires static hash values that must be regenerated and redeployed whenever a file changes, creating operational friction.

Stickler’s core contribution is a “publisher‑sign‑verify” model that works entirely with unmodified browsers. Publishers generate a digital signature for every static asset (HTML, CSS, JavaScript, images, etc.) using a private key. The signature, together with metadata such as the asset’s path, version, and timestamp, is stored either inline or in a separate manifest. The corresponding public key is published as a standard X.509 certificate. Crucially, the first piece of code that a client loads—called the bootloader—is fetched directly from the publisher’s origin over HTTPS, not from the CDN. This bootloader contains the public key and a small verification engine implemented with standard Web APIs (Fetch API and Web Crypto API).

Once the bootloader is in place, it dynamically fetches each subsequent asset from the CDN, verifies the attached signature, and only then injects the asset into the DOM. If verification fails, the asset is discarded and a warning is logged. Because verification is performed in JavaScript, no browser extensions, plugins, or modifications to the rendering engine are required. Stickler therefore preserves full compatibility with existing browsers, CDNs, and caching strategies.

The architecture is divided into four logical components: (1) a signing pipeline integrated into the publisher’s build system, (2) the bootloader delivery mechanism, (3) the unchanged CDN distribution path for signed assets, and (4) the client‑side verification engine. The authors evaluate performance on both desktop and mobile platforms. The additional network round‑trip needed to fetch the bootloader adds roughly 30–50 ms of latency, which is negligible compared to typical page load times. Signature verification using RSA‑2048 or ECDSA‑P256 consumes less than 1 ms of CPU time on modern devices, confirming that the cryptographic overhead does not impair interactivity. Moreover, because the CDN still serves the bulk of the content, cache hit rates and bandwidth savings remain essentially unchanged.

From a security perspective, Stickler establishes a clear trust boundary: the CDN is treated as an untrusted transport that may be malicious, while the publisher’s signed assets are the sole source of truth. The system thwarts any CDN‑based tampering because a forged asset will fail the cryptographic check and never execute. The only remaining attack surface is the initial bootloader fetch; the authors recommend hardening this step with HTTP Strict Transport Security (HSTS) and public‑key pinning (PKP) to mitigate certificate‑based attacks. They also discuss key management, emphasizing the need for secure storage, rotation policies, and re‑signing of assets when keys change.

Operationally, Stickler requires minimal changes to existing workflows. Publishers add a signing step to their CI/CD pipeline and host a small bootloader on their origin server. No changes are needed on the CDN side, making the solution attractive to both small sites that already rely on third‑party CDNs and large enterprises seeking to harden their delivery pipeline without redesigning their infrastructure. Limitations include the current focus on static assets; extending the model to dynamic API responses or real‑time streaming media would require additional research. The paper also notes that improper key handling could undermine the entire scheme, so robust key lifecycle management is essential.

In conclusion, Stickler demonstrates that end‑to‑end content authenticity can be achieved without altering browsers, preserving CDN performance benefits while providing strong cryptographic guarantees against content tampering. The authors suggest future work on automated key rotation, multi‑CDN support, and signature schemes for dynamic content, positioning Stickler as a practical step toward a more secure web delivery ecosystem.