ORIGIN AND APPLICATION PROTECTION
Why is your origin seeing traffic it should never have to handle?
Bots, scrapers, and malicious crawlers don't look different from legitimate traffic to a basic proxy. Unauthenticated API calls consume backend threads before they're rejected. Rate limiting that runs at the application layer fires after the damage is already being done. And when a legitimate traffic spike sends thousands of users requesting the same uncached asset simultaneously, a proxy without request coalescing forwards every single one.
The origin shouldn't be your last line of defence. It should barely know the attack happened.
Two threats your edge should be stopping
Origin protection is two distinct challenges that a disconnected security and caching stack handles poorly:
Malicious and non-human traffic wastes compute
Bots, scrapers, and spoofed crawlers consume origin CPU cycles, inflate cloud egress bills, and degrade response times for real users, not because the origin can't reject them, but because it has to process them first. Every malicious request that reaches the backend is a request your infrastructure paid to handle before refusing.
Legitimate traffic spikes create thundering herds
When thousands of users request the same uncached asset simultaneously a basic proxy forwards every request to the origin in parallel. The backend receives a flood of redundant fetches for identical content, and collapses under load that a coalescing edge would have reduced to a single upstream request.
Both problems have the same root cause: an edge that forwards rather than filters.
What unshielded origins cost your teams
Security and WAF architect
Legacy perimeter tools that run as separate network hops force a trade-off between thorough threat inspection and acceptable user latency. Every security check that adds a round trip is a check that teams are under pressure to remove or simplify.
SRE and operations lead
Origin collapses during traffic spikes are among the most stressful incidents to manage: high blast radius, immediate user impact, and pressure to resolve in minutes.
Infrastructure lead
Bots and scrapers that reach the origin generate the same egress fees and compute costs as legitimate users.
Why disconnected security and caching layers fail
Traditional security perimeter tools and separate WAF setups fail to protect backend origins efficiently for four key reasons:
Challenge 1
Cloud WAFs add cost and latency
External cloud WAFs charge per gigabyte of traffic processed and add a network hop between the user and the cache. Security inspection that should happen at memory speed at the edge instead adds round-trip time and a separate billing line.
Challenge 2
Separate security and caching hops compound latency
Running a WAF on one network hop and a cache on another means every request traverses both before reaching the origin. The latency penalty accumulates and the operational complexity of maintaining two separate systems doubles.
Challenge 3
No request coalescing means thundering herds reach the origin
A basic proxy that receives ten thousand simultaneous requests for an uncached asset sends ten thousand requests upstream. Without coalescing, every legitimate traffic spike becomes an origin incident.
Challenge 4
Backend rate limiting fires too late
Rate limiting implemented at the application layer executes after the request has already consumed a backend thread. High-volume bot attacks drain thread pools before a single request is rejected.
"Varnish is the cornerstone of how we handle scale"
Global streaming service
How Varnish stops threats at the perimeter
01
Bot and scraper mitigation at the first hop |
Forward-confirmed reverse DNS checks and behaviour analysis run at the edge. Legitimate search engines pass through. Malicious scrapers, spoofed crawlers, and automated abuse tools are identified and blocked before they reach any backend infrastructure or consume any origin compute. |
02
In-process WAF filtering |
A high-performance Web Application Firewall runs natively inside the edge cache process. Incoming payloads are scrubbed for SQL injection, XSS, and known attack signatures at the perimeter. Malicious inputs are dropped before they touch application code. |
03
Distributed perimeter rate limiting |
Edge nodes share client request rates continuously using in-memory messaging across the delivery cluster. When a client or botnet exceeds configured thresholds, subsequent requests are dropped at the edge before they consume a single origin thread. Rate limiting fires at the perimeter, not after the damage is done. |
04
Request coalescing prevents thundering herds |
Thousands of simultaneous requests for an uncached asset collapse into a single upstream fetch. All waiting clients receive the cached response simultaneously. If the backend goes offline, stale cached content keeps the platform available through the outage. |
Three deployment models for origin protection
Varnish provides three distinct deployment models to protect your application origins.
Varnish EnterpriseSelf-managed private edge
|
Best for financial institutions, government networks, and applications requiring air-gapped security or precise developer-level routing control. Deploy the software-defined engine directly onto your own physical servers, private hypervisors, VPCs, or Kubernetes clusters for absolute custody over your edge security shield. |
Varnish CDNSovereign CDN service
|
Best for fast-growing web applications, API networks, and ecommerce platforms that need robust origin protection without managing servers. Route public-facing traffic through a fully managed European-hosted CDN with built-in in-process security, edge scaling, traffic scrubbing, and DDoS mitigation. |
Varnish CDN in a BoxTurnkey partner-hosted edge
|
Best for telcos, managed service providers, and large multi-region organisations wanting dedicated on-net origin shielding without third-party cloud data inspection fees. Deploy localised edge nodes with pre-compiled security modules directly in front of your core applications. |
Resources and media
-
Building delivery resilience into cloud architectures
Lessons from the AWS US-East-1 outage
-
Stopping application-layer threats before they hit your servers
Because Varnish sits in the request path it’s in a unique position to make real-time decisions about requests, responses, and traffic policy.
-
Creating an AWS S3 shield with Varnish Enterprise
Learn how to use Varnish to shield S3 buckets and improve performance and cost efficiency. Learn more →
-
When CDNs fail: staying online with an origin shield
In this webinar we’ll show how an origin shield can save you in an outage, so you can keep reaching your audience while other websites go down.
-
Fronting Storj with Varnish on DigitalOcean
How to offload traffic from your object storage using Varnish Enterprise.
Next steps
Talk to our team to learn more about Varnish origin protection solutions
