import { Image } from ‘astro:assets’;
Last Updated: March 2026
Bad bots now account for 37% of all internet traffic — and for the first time in a decade, automated traffic has officially surpassed human visitors online. Ecommerce stores rank as the third most targeted industry, with nearly 23% of transactions coming from bots. The financial damage is staggering: businesses worldwide lose an estimated $116 billion per year to automated bot attacks.
If you run a Shopify store, you’re not immune. Bots scrape your product images, steal your pricing data, hoard your inventory during flash sales, and create fake accounts to abuse promotions. The question isn’t whether you need protection — it’s where that protection should happen.
That’s the core of the server-side vs client-side blocking debate. Understanding the difference between these two approaches isn’t just a technical exercise — it directly affects how well your store is protected against today’s increasingly sophisticated threats.
What Is Server-Side Blocking?
Server-side blocking happens before a request ever reaches the visitor’s browser. It operates at the infrastructure level — on the web server, at the network edge, or through a reverse proxy — inspecting and filtering traffic before it touches your storefront.
Think of server-side blocking as the security guard at the building entrance. Threats are identified and stopped before they ever get inside.
How Server-Side Blocking Works
Server-side protection uses several mechanisms working together:
- Web Application Firewalls (WAFs) — sit between the visitor and your server, analyzing every HTTP request against rulesets that include IP blocklists, geolocation data, traffic patterns, and known attack signatures. Malicious requests are dropped before they reach your application
- IP access rules — block, allow, or challenge traffic based on IP address, IP range, ASN (Autonomous System Number), or country of origin. AWS WAF supports up to 10,000 IP addresses per match condition
- Rate limiting — enforced at the network edge or API gateway, capping the number of requests per IP or session within a time window. Prevents scraping, brute-force attacks, and automated bulk purchasing
- Bot scoring — assigns a risk score to each visitor based on behavioral signals, request patterns, and IP reputation. High-risk visitors get blocked or challenged before accessing any content
- DDoS protection — absorbs and filters volumetric attacks at the edge, preventing malicious traffic floods from reaching your origin server
All of this happens invisibly. The legitimate customer browsing your store never knows these checks are running. The bot attempting to scrape your catalog gets stopped cold.
Server-Side Blocking in the Shopify Context
Every Shopify store already benefits from some server-side protection. All Shopify traffic passes through Cloudflare’s network, which provides baseline WAF, DDoS protection, and bot classification. Shopify Plus stores can enable additional bot protection for checkout to prevent auto-checkout bots during flash sales.
However, Shopify’s built-in protections are general-purpose. They protect the platform as a whole — not your specific store. To address threats targeting your unique business (content scrapers copying your product descriptions, competitor spy tools monitoring your pricing, bots from specific regions generating fraudulent orders), you need an additional server-side layer tailored to your store’s needs.
What Is Client-Side Blocking?
Client-side blocking happens inside the visitor’s browser, using JavaScript to detect threats and enforce security rules. Instead of filtering traffic before it arrives, client-side protection runs code on the user’s device to identify and respond to suspicious behavior.
Think of client-side blocking as a security camera inside the store. It can observe what’s happening, but by the time it spots a threat, the visitor is already inside.
How Client-Side Blocking Works
Client-side protection relies on browser-executed mechanisms:
- JavaScript bot detection agents — scripts that run in the browser to check for automation tools, analyze mouse movements, evaluate typing patterns, and collect browser fingerprints
- CAPTCHA challenges — hCaptcha, reCAPTCHA, and similar systems that require user interaction to prove human identity
- Content Security Policy (CSP) — HTTP headers that restrict which scripts can execute, preventing injection of unauthorized code
- Browser fingerprinting — collecting device attributes (canvas rendering, WebGL capabilities, installed fonts, screen resolution) to identify bot-like configurations
- Right-click and copy prevention — JavaScript that disables context menus, keyboard shortcuts, and text selection to deter casual content theft
- Developer tools detection — scripts that detect when browser dev tools are open, signaling potential scraping activity
The Fundamental Problem with Client-Side Security
Here’s the uncomfortable truth: users have complete control over what runs in their browser. Every piece of JavaScript, every detection script, every CAPTCHA challenge happens on a device the attacker controls.
This isn’t a theoretical concern. MITRE formally classifies “Client-Side Enforcement of Server-Side Security” as CWE-602 — a recognized security weakness. It was cited as part of OWASP’s #1 vulnerability category in 2021: Broken Access Control.
The fundamental principle: if protection only exists in the browser, it can be bypassed by anyone who controls the browser. And the attacker always controls the browser.
The Security Implications: A Direct Comparison
Understanding the practical security differences between these approaches is critical for making informed protection decisions.
Bypass Resistance
Server-side blocking operates outside the attacker’s reach. A visitor can’t disable your WAF rules, modify your rate limiting, or tamper with your IP blocklists — because those systems run on infrastructure they don’t control.
Client-side blocking is vulnerable to multiple bypass techniques:
| Bypass Method | Difficulty | Effectiveness |
|---|---|---|
| Disable JavaScript | Trivial | Defeats all JS-based protection |
| Browser developer tools | Easy | Allows inspection and modification of detection scripts |
| Proxy tools (Burp Suite) | Moderate | Intercepts and modifies validation functions |
| Headless browser stealth plugins | Moderate | Puppeteer Stealth, Playwright Stealth mimic human behavior |
| Anti-detect frameworks (Camoufox) | Advanced | Implements fingerprint spoofing at the C++ level |
| API-direct attacks | Moderate | Bypasses the frontend entirely, hitting your APIs without loading any JavaScript |
The most concerning bypass is also the simplest: disabling JavaScript. With a single browser setting, every client-side protection disappears instantly. No sophisticated tools needed.
Performance Impact
Server-side blocking processes requests before they reach your store. Blocked traffic never loads your pages, never executes your JavaScript, and never consumes your server resources. Your legitimate customers experience zero performance impact.
Client-side blocking adds JavaScript to every page. This has measurable consequences:
- JavaScript accounts for approximately 26% of average page weight
- Every additional second of page load time drops conversion rates by 4.42%
- Detection scripts, fingerprinting libraries, and CAPTCHA systems all compete for browser resources with your product images, checkout scripts, and analytics
For ecommerce stores where page speed directly correlates with revenue, any unnecessary client-side overhead is a cost.
API Protection
This is where the gap between server-side and client-side approaches becomes most dramatic.
Server-side blocking protects your entire application — the storefront, the checkout, the admin panel, and every API endpoint. Bots that attempt to scrape product data through Shopify’s APIs, submit fraudulent orders through checkout endpoints, or enumerate gift card balances through backend services all get filtered.
Client-side blocking only works where JavaScript runs — the visible frontend in a browser. According to the Imperva Bad Bot Report, 44% of advanced bot traffic now targets APIs directly, bypassing the storefront entirely. If your protection only exists in browser JavaScript, nearly half of sophisticated attacks go completely undetected.
Centralized Management
Server-side blocking allows security policy updates from a single location. Change a rule on the server, and it immediately applies to all traffic — every page, every endpoint, every visitor. No code deployments, no JavaScript updates, no cache invalidation needed.
Client-side blocking requires deploying JavaScript changes across every page of your site. Updates may be cached by CDNs or browsers, creating windows where old security rules remain active. And if an attacker has already compromised or bypassed the client-side script, no amount of updates will help until the fundamental vulnerability is addressed.
Server-Side vs Client-Side: The Complete Comparison
| Factor | Server-Side Blocking | Client-Side Blocking |
|---|---|---|
| Where it runs | Web server / network edge | Visitor’s browser |
| Can be bypassed by disabling JS | No | Yes |
| Visible to attackers | No — rules are hidden | Yes — all code is inspectable |
| Performance impact on visitors | None — blocked traffic never loads | Adds page weight and latency |
| Protects APIs | Yes | No |
| Works without JavaScript | Yes | No |
| Centralized updates | Yes — change once, apply everywhere | Requires deployment across all pages |
| Detects browser-level signals | Limited | Yes (mouse movements, fingerprints) |
| PCI DSS compliance | Required (WAF) since March 2025 | Not a compliance requirement |
| False positive handling | Can be complex for IP/geo rules | Can frustrate users with CAPTCHAs |
The comparison makes the hierarchy clear: server-side blocking is the foundation, and client-side measures serve as a supplementary detection layer.
Why Server-Side Must Be Your Foundation
Research confirms what the technical analysis suggests.
The Sansec Study: 210,000 Stores Monitored
Security firm Sansec monitored over 210,000 online stores with payment skimmers over five years. Their critical finding: virtually all malicious injections occurred through direct server compromises, not client-side supply chain attacks. The last successful client-side supply chain attack they tracked occurred in 2019.
Their conclusion is direct: “When malicious code appears on your site, it means your infrastructure has already been compromised.” Client-side security can neutralize malicious frontend code in theory — but an attacker who controls the server can simply remove the security script, modify its configuration, or inject malicious code before it loads.
The Bot Detection Reality
F5 Labs’ 2025 Advanced Persistent Bots Report found that only 2.8% of websites are fully protected against bots — down from 8.4% the previous year. Over 61% of websites remain completely unprotected.
Detection rates across widely-used client-side vendors range from just 6% to 42% — meaning even the best client-side-only solutions miss the majority of sophisticated bots. The remaining attacks succeed because bots have evolved: AI-driven bots now account for nearly 60% of automated traffic, mimicking mouse movements, varying browsing patterns, and adjusting timing to defeat JavaScript-based detection.
The Financial Stakes
The numbers underscore why getting protection architecture right matters:
- 98% of companies that experienced bot attacks lost revenue
- 24% of companies report a single bot attack costing $500,000+
- Online merchants lose an average of 3.6% of revenue to bot-related fraud and operational costs
- Account takeover attacks increased 250% in 2024
For a Shopify store generating $500,000 per year, that 3.6% average translates to $18,000 in annual losses — far more than the cost of proper server-side protection.
Common Threats and How Each Approach Handles Them
Let’s examine how server-side and client-side blocking respond to the specific threats Shopify stores face daily.
Content Scraping
Bots that scrape your product descriptions, pricing, and images to clone your store or undercut your prices.
Server-side response: Rate limiting blocks rapid-fire requests. IP reputation databases identify known scraping services. Bot scoring catches automated patterns before content is served. The scraper never receives the data.
Client-side response: JavaScript can detect some scraping tools and disable right-click/copy. But headless browsers with stealth plugins bypass these checks entirely. Scrapers that use API calls skip the frontend altogether. The content is already downloaded before detection triggers.
Verdict: Server-side is significantly more effective for stopping automated scraping at scale.
Credential Stuffing
Bots testing thousands of stolen username/password combinations against your customer login.
Server-side response: Rate limiting caps login attempts per IP and per account. IP reputation flags known attack sources. Failed attempt patterns trigger automatic blocks. Attack traffic is stopped at the infrastructure level.
Client-side response: CAPTCHA challenges add friction but can be solved by CAPTCHA farms. JavaScript detection can identify some automation, but sophisticated tools mimic human login behavior convincingly.
Verdict: Server-side rate limiting and IP-level blocking are essential. Client-side CAPTCHA provides a supplementary friction layer.
Inventory Hoarding
Bots adding limited items to cart to deplete your stock during product launches.
Server-side response: Rate limiting on cart operations. Session analysis identifying rapid-fire add-to-cart behavior. IP blocking on known bot networks. Cart quantity limits enforced at the server.
Client-side response: JavaScript can detect automation tools on the checkout page, but bots hitting the cart API directly bypass all frontend detection. Browser-level fingerprinting helps identify repeat offenders but doesn’t prevent the initial attack.
Verdict: Server-side enforcement is critical for protecting inventory. Client-side detection alone cannot prevent API-level cart manipulation.
Competitor Spy Tools
Browser extensions like PPSPY, Koala Inspector, and ShopHunter that expose your product data, traffic estimates, and installed apps to competitors.
Server-side response: Can detect and block requests from known spy tool infrastructure. Server-side rules prevent spy tools from accessing your store data at the network level.
Client-side response: JavaScript-based detection can identify when spy extensions are active in the browser and blur content or block access. This works for casual intelligence gathering but sophisticated tools can evade detection.
Verdict: Both approaches have value here. Server-side blocks infrastructure-level data collection, while client-side detection addresses browser extension threats.
Building Defense in Depth: The Layered Approach
Security professionals agree: no single layer provides complete protection. The correct architecture uses defense in depth — multiple complementary layers where each catches what the others miss.
The Recommended Security Stack for Shopify Stores
Layer 1: Network Edge (Server-Side)
- WAF rules filtering known attack patterns
- IP and geographic blocking for high-fraud regions
- DDoS absorption preventing traffic floods
- Bot scoring and classification
Layer 2: Application Level (Server-Side)
- Rate limiting on all sensitive endpoints (login, cart, checkout, APIs)
- Input validation and parameterized queries
- Session management and velocity checks
- Authentication enforcement
Layer 3: Browser Level (Client-Side — Supplementary)
- Content protection (right-click, copy, developer tools detection)
- Browser fingerprinting for bot identification
- CAPTCHA challenges as a friction layer for suspicious sessions
- Spy tool extension detection
Layer 4: Monitoring and Response
- Real-time blocked traffic analytics
- Attack pattern identification
- False positive monitoring and adjustment
- Regular rule review and optimization
The key word is supplementary. Client-side measures add value as an additional detection layer, but they should never be the primary — or only — line of defense. As Sansec’s research puts it: “To effectively protect against digital threats, you need to secure your servers first.”
Why the Order Matters
Consider what happens when each layer fails:
- If server-side blocking fails, the attacker has full access to your application, APIs, and data. Client-side protections may slow them down but cannot prevent the breach
- If client-side blocking fails, the attacker can operate freely in the browser — but server-side protections still guard your APIs, enforce rate limits, and block malicious IPs
This asymmetry is why server-side protection must be the foundation. It provides the irreducible minimum of security that client-side measures build upon, not replace.
Implementing Server-Side Protection for Your Shopify Store
Getting server-side protection right doesn’t require a security engineering team. Here’s a practical approach for Shopify merchants.
Step 1: Assess Your Threat Landscape
Before configuring protection, understand what you’re defending against:
- Check your analytics — what percentage of your traffic comes from bots? (If your bounce rate seems unusually high or low, bot traffic may be skewing your data)
- Review geographic patterns — are you getting significant traffic from countries you don’t sell to?
- Monitor checkout behavior — are you seeing fraudulent orders, credential stuffing attempts, or inventory hoarding?
- Check for content theft — search your product descriptions in quotes on Google. If other sites appear, your content is being scraped
Step 2: Configure Geographic and IP Blocking
Start with the highest-impact server-side rules:
- Block countries you don’t ship to and that generate significant bot traffic
- Block known bot IP ranges associated with data centers and proxy services
- Create allowlists for IP ranges you know are legitimate (your offices, warehouses, trusted partners)
Step 3: Enable Bot Detection and Rate Limiting
- Set rate limits on sensitive pages (login, cart, checkout, search)
- Enable bot scoring to automatically classify and filter automated traffic
- Configure challenge pages for suspicious visitors — rather than outright blocking, present a verification step that humans pass easily but bots fail
Step 4: Add Client-Side Protection as a Supplement
Once your server-side foundation is solid, add client-side measures for additional coverage:
- Content protection — right-click prevention, copy blocking, developer tools detection
- Browser extension detection — identify and respond to known spy tools
- Image protection — prevent drag-and-drop and screenshot-based image theft
Step 5: Monitor and Adjust
Protection isn’t a set-and-forget configuration. Review your blocked traffic dashboard regularly to:
- Identify new attack patterns
- Check for false positives (legitimate customers being blocked)
- Adjust geographic rules as your market changes
- Update IP blocklists as bot networks evolve
Kedra Shield provides this complete server-side protection stack for Shopify stores. It combines country and city-level blocking, IP range management, VPN and proxy detection, bot filtering, and content protection — all managed from a single dashboard. The server-side architecture means threats are stopped before they reach your storefront, with no JavaScript overhead slowing down your pages for legitimate customers.
When Client-Side Protection Makes Sense
While server-side blocking should be your foundation, client-side measures still have legitimate use cases:
Content Deterrence
Right-click prevention, copy blocking, and developer tools detection won’t stop a determined attacker — but they stop casual theft. Research suggests these measures deter approximately 90% of casual content thieves who use the simplest methods (right-click, drag-and-drop, Ctrl+C). That’s not a complete solution, but it significantly reduces the volume of stolen content.
Browser Extension Detection
Spy tool detection is inherently a client-side operation because the extensions run inside the browser. Server-side blocking can identify some spy tool infrastructure, but detecting whether a specific visitor has Koala Inspector or PPSPY active requires browser-level inspection.
User Experience Signals
Client-side scripts can collect behavioral data (mouse movements, scroll patterns, typing cadence) that helps identify sophisticated bots mimicking human behavior. This data is most valuable when sent to the server for analysis — combining client-side signal collection with server-side decision-making.
The Right Mental Model
Think of the two approaches this way:
- Server-side blocking = the lock on your door, the alarm system, the security patrol
- Client-side blocking = the “No Trespassing” sign, the window film, the motion-sensor light
Both have value. But you’d never rely solely on a “No Trespassing” sign to protect your business.
Frequently Asked Questions
Is client-side blocking useless?
No — it provides value as a supplementary layer. Content protection features (right-click prevention, copy blocking) deter casual theft effectively, and browser-level detection catches spy extensions that server-side blocking can’t see. The problem arises when client-side protection is the only layer. Any determined attacker can bypass browser-based defenses, so server-side blocking must serve as the foundation.
Can bots really bypass JavaScript protection that easily?
Yes. Disabling JavaScript — the simplest bypass — requires changing a single browser setting. More sophisticated tools like Puppeteer Stealth and Camoufox automate this at scale, mimicking human browser fingerprints convincingly enough to defeat most detection scripts. The Imperva Bad Bot Report found that AI-driven bots now account for nearly 60% of automated traffic, using behavioral mimicry that defeats JavaScript-based detection.
Does server-side blocking slow down my Shopify store?
No — it’s the opposite. Server-side blocking filters malicious traffic before it reaches your store, actually reducing server load and improving performance for legitimate visitors. Bot traffic that would otherwise consume server resources, bandwidth, and database queries is eliminated at the network edge. Client-side blocking, by contrast, adds JavaScript to every page, increasing load times.
What about false positives? Won’t server-side blocking accidentally block real customers?
False positives are a legitimate concern with any blocking approach. The key is smart configuration: start with high-confidence rules (blocking known bot IP ranges, countries you don’t serve), use challenge pages instead of outright blocks for borderline cases, and monitor your blocked traffic dashboard regularly. Kedra Shield provides detailed analytics on blocked visitors so you can quickly identify and address false positives.
How does this apply to Shopify specifically?
All Shopify stores benefit from Cloudflare’s baseline protection, but that covers platform-wide threats — not store-specific ones. Your unique content, pricing data, customer accounts, and competitive intelligence are only protected by additional layers you implement yourself. Server-side security apps add the store-specific protection layer that Shopify’s built-in infrastructure doesn’t provide.
Is server-side blocking required for PCI compliance?
The latest PCI DSS version, effective since March 2025, requires WAF (Web Application Firewall) protection for businesses handling payment data. While Shopify handles PCI compliance for your checkout, implementing server-side security demonstrates due diligence in protecting customer data throughout the shopping experience — not just at the payment step.
Can I use both server-side and client-side protection together?
Absolutely — this is the recommended approach. Security professionals call it “defense in depth.” Server-side blocking forms the foundation (WAF, IP blocking, rate limiting, bot scoring), while client-side measures add supplementary detection (content protection, extension detection, behavioral analysis). Each layer catches threats the other might miss, creating comprehensive protection.
Protect Your Store Where It Matters Most
The data is clear: bot traffic is increasing, attacks are getting more sophisticated, and client-side-only protection is falling behind. With only 2.8% of websites fully protected against bots and detection rates for client-side tools ranging from just 6% to 42%, the gap between protected and unprotected stores is widening.
Server-side blocking isn’t just the technically superior approach — it’s the only approach that addresses the full spectrum of modern threats. It stops bots before they consume your resources. It protects APIs that client-side scripts can’t reach. It works regardless of JavaScript, browser settings, or stealth tools. And it does all of this without adding a millisecond of load time for your customers.
Kedra Shield brings server-side protection to your Shopify store with country and city blocking, IP range management, VPN and proxy detection, bot filtering, and content protection — all working at the infrastructure level to stop threats before they reach your storefront. Combined with its client-side content protection features, it delivers the layered defense-in-depth approach that security professionals recommend.
Your store’s security is only as strong as its weakest layer. Make sure that layer isn’t running in the browser.
Kedra Team
Expert insights on Shopify development and e-commerce growth strategies.