Cache poisoning occurs when malicious data is injected into a browser's cache, causing it to serve compromised content even after the original attack. This can affect both browser and DNS caches, potentially redirecting users to malicious sites or serving altered JavaScript. From a client-side security perspective, implementing proper cache controls, using HTTPS, and validating cached resources help prevent poisoning attacks. Modern security headers like Cache-Control and proper SSL/TLS configuration are crucial defenses.
Cache poisoning is the insertion of malicious or incorrect data into a cache so that later requests are served the tampered version. Several layers can be affected. Web cache poisoning abuses how a CDN or reverse proxy builds its cache key, tricking it into storing an attacker-influenced response that is then handed to other users. DNS cache poisoning corrupts a resolver's records so a hostname points at an attacker's server. A browser's own cache can also retain a manipulated resource. In each case the poisoned entry persists after the original request, letting one interaction affect many subsequent visitors until the cache expires or is purged.
A poisoned cache turns a single injected response into a durable, wide-reaching attack. If the manipulated entry is a JavaScript file, every visitor served from that cache runs the attacker's code, which can steal data, redirect users, or deface the page, all while the origin server's own logs look normal. DNS poisoning can silently reroute traffic to a lookalike site for phishing or credential theft. Because the malicious content is delivered from infrastructure that users and browsers already trust, it bypasses many defenses and can be hard to spot. The blast radius depends on how widely the cache is shared and how long entries live.
Reduce the attack surface by serving everything over HTTPS with valid certificates, which blocks the on-path tampering that seeds many poisoning attacks, and pair it with HSTS. Configure caches to key on every request input that affects the response, avoid caching decisions based on unkeyed headers, and set deliberate Cache-Control and TTL values. Use DNSSEC-aware resolvers to resist DNS poisoning, and Subresource Integrity so a browser rejects a script whose hash no longer matches. Where a poisoned cache serves an altered third-party script, cside's payload analysis at its Script method can detect that the code's behavior has changed and block it, independent of where the file was cached.
No, though they are related. Cache poisoning stores a harmful response so that others receive it. Web cache deception instead tricks a cache into storing a victim's private, personalized page under a URL an attacker can later request, exposing that user's data. One weaponizes shared content; the other leaks confidential content.
HTTPS encrypts and authenticates traffic between the browser and server, so an on-path attacker cannot silently alter a response and have it cached as legitimate. It does not fix flaws in how a CDN builds cache keys or in DNS, so it is necessary but not sufficient; correct cache configuration and DNSSEC still matter.
We answer client-side security questions every day. Bring yours.