The Cache Is a Security Layer: Stopping Application-Layer Threats Before They Hit Your Servers

Varnish is a programmable HTTP engine and cache that operates at the application layer. Its standard role is to accelerate web and API performance by storing and serving content at the edge, reducing load on backend systems and speeding up response times. Because it sits in the request path and handles every inbound HTTP interaction, it’s also in a unique position to make real-time decisions about requests, responses, and traffic policy.

As threats have shifted from volumetric network attacks to targeted abuse at Layer 7, the application layer has become a practical and effective place to enforce security, manage privacy, and control how traffic moves through the system.

Some of the low-cost, sustained attack patterns we see today include:

• Credential stuffing on login pages, with distributed IPs to avoid per-node limits
• Scraping of search or pricing endpoints
• CI/CD abuse, where internal APIs or build systems are unintentionally exposed
• Token manipulation in streaming or paywalled systems, bypassing expiry or geo checks
• Evasion tactics, such as high-entropy user agents, CAPTCHA farms, and rotating IP headers

A new category of traffic is emerging too: LLM-based crawlers. Alongside this, more services are exposing internal dashboards, pipelines, and tools, often inadvertently, simply as a trade-off for speed or ease of access.

When systems that once scaled comfortably are now under constant background load, it’s a financial as well as technical problem. At that scale, it matters where you make security decisions.

The Cache as a Decision Layer

Security isn’t one-size-fits-all, and Varnish is built to be flexible, forming part of a layered strategy that fits real-world deployments and can be adapted and extended based on the level of protection you need. It can sit between users and origin infrastructure, at the edge, as a shield between CDN and origin, or as an internal enforcement point, depending on what the architecture demands. Varnish isn’t necessarily a displacement for existing CDNs like Akamai (though many enterprises do build private CDNs with Varnish to have complete control over performance, cost, routing, compliance, and data residency). Rather, many of our users employ it as a critical shield closer to the origin. Even with a powerful CDN in place, a significant amount of malicious or unwanted traffic can still pass through, hitting your backend systems and consuming resources. Placing Varnish in this position ensures that only clean, legitimate requests are ever allowed to reach core infrastructure.

Varnish is a cache, storing and serving copies of content to reduce load on backend systems, but that is understating what it does. At scale, it becomes a programmable decision layer: a high-performance checkpoint handling the early part of every request, applying logic based on headers, cookies, IPs, tokens, timing, and more. Using Varnish Configuration Language (VCL), engineers can write custom logic to inspect requests and make real-time decisions without ever hitting their backend. This has been part of Varnish’s DNA for almost twenty years, first described as a tiny layer of C in the web stack for high-level optimization. That same principle now extends to security and policy enforcement at the delivery layer.

The cache is a useful place to enforce policy. It’s close enough to the user to act quickly, but upstream enough to shield backend systems from unnecessary load. Many security tools sit further downstream; at that point, a malicious request has already consumed valuable compute, storage, and processing cycles. Ideally, we make a call earlier: should we serve this, pass it on, delay it, or block it altogether? For performance, this reduces load. For security, it stops requests before they turn into something more dangerous. For operators, it gives back control over what reaches core infrastructure. Varnish gives you a programmable interface to do exactly that: define rules, set thresholds, and apply logic where it’s most effective.

Security Built In

The ability to respond instantly at the edge is a critical need for our customers.

“For us it is important to access an unmatched, simplified, clean and easy-to understand toolset to manipulate inbound request URLs and headers. Being able to remediate misconfigured or misemployed applications in the wild at the edge without needing separate components or layers (e.g., web server scripting) is everything.” Senior Technology Infrastructure Engineer, RTÉ

Reverse proxies have long played a role in security, handling TLS, controlling access, and shaping traffic. It’s no surprise that many of our customers use Varnish as a key enforcement layer, whether at the edge, as an origin shield, or securing internal infrastructure. Varnish can act as the sole point of ingress and egress for a company’s network: it can proxy and cache upstream responses, so internal services don’t need to be exposed directly. You can control flow, reduce load, and improve latency without opening more doors than you have to. Varnish Enterprise builds on this by bringing more flexibility and programmability to the table, especially for Layer 7 use cases. In recent years we’ve been widening the scope of Varnish’s security tooling, building out a more complete security framework at the cache layer:

• Token-based authentication, for APIs and streaming endpoints
• IP, header, and cookie filtering, tied to simple rulesets
• Geo-blocking and reverse DNS-based bot filtering
• Optional WAF support, using ModSecurity and OWASP rules
• TLS/mTLS termination and visibility
• Shared KV storage, so you can apply logic across a cluster
• Bot protection integrations, including partnerships with third-party providers for advanced detection

While security is often seen as a trade-off with performance, placing enforcement closer to the edge can actually improve performance when handled properly. Unwanted traffic gets handled early. Malformed requests don’t hit backend systems. Expensive resources are saved for real users. A programmable cache like Varnish Enterprise is well suited to this. Fast startup, low memory use, and predictable under pressure.

Where We’re Going

We’re continuing to build toward more robust enforcement: anomaly detection, session tracking, flexible rate control, and better visibility. This means adding security in progressive layers so you can start with the essentials and add more advanced capabilities as your requirements grow. Not every customer will need every capability, but our direction is clear. Varnish is moving from a pure delivery engine to a platform that also delivers integrated security and compute. This is a proven path in content delivery, because the closer security is to the delivery layer, the more effective it is. Customers already trust Varnish to deliver at speed and scale; they should be able to trust it to protect with the same confidence. We are building this security capability in progressive layers so customers can choose the level of protection that matches their needs today, with the option to expand tomorrow. This approach makes it possible to start with essentials and add more advanced defenses as risk, scale, and compliance requirements grow, while keeping performance uncompromised and delivering clear value at every stage.

We’re expanding Varnish’s security toolset, with more flexible enforcement logic, session handling and anomaly detection. Several new features in this space are close to release. They’ll extend the security posture you can build directly into your Varnish deployment, at the edge, as a shield, or deeper inside your infrastructure, without relying on third-party services or downstream systems.

One of the most significant new additions is Global Rate Limiting: a distributed enforcement layer that coordinates protection across all Varnish nodes. This is a non-trivial problem in a distributed system, where a simple per-node rate limit can be easily bypassed. Our new system will enable fair usage enforcement, protect against bursty or abusive traffic, and help teams contain costs by avoiding unnecessary scale-out.