Seatext library / BotRefund evidence
Should You Block Bot Traffic at the CDN Edge or at Your Origin Server?
Block bots at the CDN edge whenever possible. Stopping them at the origin still lets malicious traffic consume bandwidth, connection slots, and server resources while the request is evaluated. Edge blocking prevents that waste...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Block bots at the CDN edge whenever possible. Stopping them at the origin still lets malicious traffic consume bandwidth, connection slots, and server resources while the request is evaluated. Edge blocking prevents that waste before it reaches your infrastructure. This article explains the trade-offs, shows you how to decide, and gives practical examples.
| Criterion | CDN Edge Blocking | Origin Server Blocking | Takeaway |
|---|---|---|---|
| Bandwidth consumption | Blocked before entering your network | Traffic traverses full path to origin | Edge saves egress/ingress costs |
| Connection slots | Freed at edge; origin never sees the handshake | Origin TCP/HTTP slots occupied during inspection | Edge protects capacity for real users |
| Server CPU & memory | Zero impact on application servers | Inspection logic runs on your compute | Edge offloads detection workload |
| Detection richness | Limited to headers, IP reputation, TLS fingerprint | Full access to request body, cookies, session state | Origin sees more context; edge sees less |
| Rule deployment speed | Global propagation in seconds to minutes | Requires code deploy or config reload | Edge reacts faster to new threats |
| False-positive blast radius | Affects all properties on that CDN zone | Scoped to single application | Origin limits collateral damage |
Why the blocking point matters
Every bot request that reaches your origin consumes resources before you can reject it. The TCP handshake, TLS negotiation, HTTP parsing, and any application-layer inspection all burn CPU cycles, memory, and network bandwidth. Multiply that by thousands of automated requests per second and the cost becomes measurable in both infrastructure spend and degraded performance for legitimate visitors.
Edge blocking moves that decision upstream. The CDN evaluates the request at a point of presence (PoP) close to the attacker, drops it, and never forwards it to your origin. Your servers stay focused on real traffic.
Consider a typical e-commerce site during a flash sale. A botnet sends 50,000 requests per second. If you block at the origin, each request still travels through your load balancer, web server, and application code. That consumes 50,000 TCP connections, 50,000 TLS handshakes, and 50,000 application-level checks. Even if you reject them all, you have paid for the network and compute. Edge blocking stops that flood at the CDN, so your origin sees only a fraction of the traffic.
How CDN edge blocking works
Modern CDNs run a detection engine at each PoP. They combine IP reputation lists, TLS fingerprinting (JA3/JA3S), HTTP header anomalies, rate-limiting counters, and behavioral heuristics. When a request matches a block rule, the CDN returns a 403 or serves a challenge page without ever contacting your origin.
Because the engine runs on shared infrastructure, you get global rule propagation in seconds. A new bot signature pushed by the vendor appears at every PoP almost instantly. The trade-off is visibility: the edge sees only what travels over the wire—headers, IP, TLS parameters—not your application cookies, session state, or request bodies.
Some edge providers now offer richer detection. For example, BotRefund uses 106 independent checks across browser, network, device, and behavior. These checks include hardware and GPU fingerprinting, empty font canvas, suspicious ports, monitor sync anomalies, and more. The AI model weighs all signals together to achieve 99% accuracy. This kind of edge detection can catch bots that look like legitimate traffic at the network layer.
How origin blocking works
Origin blocking means your application (or a WAF module in front of it) inspects every request after it has already arrived. You have full context: authenticated session IDs, POST bodies, business-logic parameters, and downstream service responses. This enables precise rules—"block only when user X attempts action Y from a new device."
The downside is resource consumption. Every blocked request still paid the network and compute price to reach that inspection point. Rule changes require a deploy or configuration reload, which can take minutes to hours depending on your CI/CD pipeline.
Origin blocking also gives you the ability to log full request and response data. If you need to audit every request for compliance, origin inspection may be mandatory. But that logging itself consumes storage and compute. You must weigh the cost of that visibility against the cost of letting bots consume resources.
Key trade-offs and decision criteria
- Traffic volume: High-volume sites save more by stopping bots early. If you get millions of requests per day, edge blocking can cut origin load dramatically.
- Attack profile: Volumetric scrapers and credential stuffing benefit most from edge blocking; targeted business-logic abuse may need origin context. For example, a bot that logs in with stolen credentials and then performs a specific action needs application-level checks.
- False-positive tolerance: If a false block on the CDN affects multiple brands or subdomains, origin scoping is safer. A single misconfigured edge rule can take down an entire zone.
- Team velocity: Teams that can push WAF rules in minutes may prefer origin; teams needing instant global updates lean edge. Edge rules propagate in seconds, which is critical during an active attack.
- Compliance: Some regulations require inspection logs to stay within your controlled environment. If you must keep all data on-premises, origin blocking may be the only option.
There is also a cost dimension. Edge blocking reduces bandwidth bills and frees up origin compute. But edge WAF rules often come with a price tag. Compare the cost of edge protection against the cost of scaling your origin to handle bot traffic. In most cases, edge blocking is cheaper.
Practical scenarios
Scenario 1: E-commerce flash sale
Expected bot surge: scalpers, inventory hoarders. Use CDN edge rate limits and known-bot IP blocks to absorb 90% of noise. Keep origin rules for checkout-specific anomalies (e.g., same session adding 50 items in 2 seconds). This hybrid approach protects both infrastructure and business logic.
Scenario 2: SaaS API endpoint
Authenticated API traffic. Edge can block obvious scrapers by API key reputation and TLS fingerprint. Origin must enforce per-customer quotas and business-logic abuse that only the application understands. For example, a customer using a free tier might try to call an endpoint 10,000 times per minute. Edge rate limits can catch that, but only origin knows the customer's plan.
Scenario 3: Media site with paywall
Bots bypassing paywall via headless browsers. Edge detects headless signatures (missing fonts, canvas anomalies). Origin correlates with subscription state to avoid blocking paying users on corporate VPNs. A paying user might have a clean IP but a headless browser signature if they use a privacy tool. Origin can check the session cookie to confirm they are a subscriber.
Scenario 4: Ad-heavy content site
Bot clicks on ads steal up to 20% of Google and Meta ad budget. Edge blocking can filter obvious bots, but sophisticated bots mimic human behavior. BotRefund uses behavioral checks like ghost click detection, trap interactions, and mouse movement analysis. It captures video proof of each bot click and negotiates refunds with ad platforms. This is a case where edge detection alone may not be enough; you need client-side signals.
Limitations and when this advice does not apply
- If your CDN does not support custom WAF rules or behavioral detection, edge blocking may be too coarse. Some CDNs only offer basic IP blocking.
- If you run on-premises without a CDN, the question is moot—invest in a network-layer DDoS scrubber first.
- If regulatory audit trails require full request/response logging in your own data center, origin inspection may be mandatory.
- Single-tenant applications with low traffic may not see measurable savings from edge offload. If you get 100 requests per second, the cost of edge WAF may exceed the savings.
- Edge blocking cannot see encrypted request bodies. If you need to inspect POST data for fraud, you must do that at the origin.
Implementation best practices
Start with a hybrid approach. Enable edge blocking for known bots and volumetric attacks. Use origin rules for business logic and authenticated abuse. Monitor both layers to tune false positives.
Use a phased rollout. First, run edge rules in monitor-only mode. Log what would have been blocked. Compare with origin logs to see if any legitimate traffic would have been affected. Then enable blocking gradually.
Set up a bypass mechanism. If a user is falsely blocked, they should be able to request a review. A simple header or a CAPTCHA can let them through. This reduces the blast radius of false positives.
Measure the impact. Track origin CPU, bandwidth, and error rates before and after enabling edge blocks. Look for reduced 5xx errors during bot spikes. Also track conversion rates to ensure real users are not affected.
Key facts
| Fact | Detail | Source |
|---|---|---|
| Bot detection signals | 106 independent checks across browser, network, device, and behavior | S1 |
| Detection accuracy claim | 99% accuracy through AI corroboration of multiple signals | S1 |
| Ad budget impact | Bot clicks steal up to 20% of Google and Meta ad spend | S2 |
| Refund recovery | BotRefund proves bot clicks, negotiates with Google and Meta, gets money back | S2 |
| Setup time | Add to website in about one minute, no credit card required | S2 |
| Customer refund success | 83% of customers successfully get a refund | S2 |
FAQ
Does edge blocking hide attack data from my security team?
Most CDNs export blocked-request logs to SIEM or storage buckets. You still see volume, signatures, and source IPs—just not the full request body. If you need body data, you can configure the CDN to forward a sample.
Can I combine both layers?
Yes. Use edge for volumetric and known-bot traffic; use origin for business-logic and authenticated abuse. This defense-in-depth approach is common. Many enterprises run both and tune rules based on attack patterns.
What if my CDN WAF has high false positives?
Start with monitor-only rules, tune thresholds, then enable block. Keep a quick bypass path (e.g., a header your origin sets for verified users). Also consider using a client-side detection tool like BotRefund to add behavioral signals that reduce false positives.
How do I measure the savings?
Compare origin CPU, bandwidth, and error-rate metrics before and after enabling edge blocks. Look for reduced 5xx errors during bot spikes. Also track infrastructure costs—if you are on a pay-as-you-go cloud, you will see lower bills.
Does BotRefund replace my CDN WAF?
No. BotRefund adds client-side and behavioral signals (106 checks) that feed an AI model for 99% accuracy. It complements network-layer blocking by catching bots that look like legitimate traffic at the edge. You can use both together.
What is the typical refund recovery timeline?
BotRefund captures video proof of each bot click, exports a report, and you send it to your Google or Meta rep. Approval rates across clients are reported at 83%. The timeline depends on the ad platform's review process, but many clients see refunds within weeks.
Can I test BotRefund without committing?
Yes. The free bot audit installs in about one minute, no credit card required, and shows you the bot traffic hitting your site. You can see the data before deciding to use the full service.
What about bots that use residential proxies?
Residential proxies make IP reputation less useful. Edge blocking may miss them. That's where behavioral detection helps. BotRefund's checks like empty font canvas and monitor sync anomaly can catch headless browsers even on residential IPs.
How often should I review my bot rules?
At least monthly. Bot tactics change quickly. Review logs, adjust thresholds, and add new signatures. Edge rules can be updated in seconds, so take advantage of that agility.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.