Storefront-Level vs Server-Level Blocking
Kedra Shield operates at the storefront level. Understanding what this means — and what it does not mean — helps set correct expectations.
How Kedra Shield Works
Kedra Shield runs as a theme app embed — JavaScript that executes in the visitor’s browser when your store page loads. It evaluates the visitor against your configured rules and blocks them by:
- Replacing the page content with a full-screen block page overlay.
- Intercepting and rejecting cart and checkout requests.
- Logging the blocked visit in your analytics.
This happens within milliseconds of page load, but it happens after Shopify has already started serving the page.
What Storefront-Level Blocking Can Do
- Block visitors from viewing your products and store content.
- Prevent blocked visitors from adding items to cart.
- Prevent blocked visitors from completing checkouts.
- Detect and block VPNs, proxies, bots, and other threats.
- Enforce country, city, IP, ASN, and referrer blocking rules.
- Protect content from copying, right-clicking, and scraping.
- Log and analyze all blocked and allowed visitors.
What Storefront-Level Blocking Cannot Do
Prevent sessions from being recorded in Shopify or Google Analytics
Analytics tools record the visit the moment the URL is accessed — before any app-level code can run. See Why Blocked Visitors Still Appear in Analytics.
Block at the network level
Kedra Shield cannot prevent the initial HTTP request from reaching Shopify’s servers. The request arrives, Shopify starts processing it, and then Kedra Shield intercepts on the client side.
Block visitors who disable JavaScript
If a visitor has JavaScript disabled in their browser, the app’s blocking scripts cannot run. However, this is extremely rare — modern browsers have JavaScript enabled by default, and most Shopify themes require JavaScript to function.
Block headless browsers or server-side scrapers that don’t execute JavaScript
Sophisticated scrapers that fetch raw HTML without executing JavaScript will bypass client-side protections. Bot detection helps by identifying these visitors at the network level based on their IP, provider, and risk signals, but the content protection features (right-click blocking, DevTools blocking, etc.) rely on JavaScript execution.
How Server-Level Blocking Differs
Server-level or edge-level blocking operates at the network layer — between the visitor and Shopify’s servers. The visitor’s request is intercepted and rejected before Shopify even knows about it.
This means:
- No session is recorded in any analytics tool.
- No page content is ever sent to the visitor.
- The blocking is invisible — the visitor receives a connection error or redirect.
Server-level blocking requires dedicated infrastructure (firewalls, CDN rules, or reverse proxies) that sits in front of Shopify. This is not possible through a Shopify app, which by design runs within the storefront.
The Fail-Open Trade-Off
Kedra Shield uses a fail-open design: if anything goes wrong during the security check (API timeout, detection service down, missing configuration), the visitor is allowed through rather than blocked.
This is an intentional trade-off. The alternative — fail-closed — would risk locking out legitimate customers during outages. For an e-commerce store, a lost sale is worse than a bot getting through temporarily.
Specific fail-open behaviors:
- If the IP detection API is unreachable, visitors are allowed through.
- If a visitor’s country or city cannot be determined, they are allowed through (even in whitelist mode).
- If the security check takes longer than 3 seconds, queued cart and checkout requests are released.
- If any blocker encounters a JavaScript error, it allows the visitor through.
Next Steps
- Why Blocked Visitors Still Appear in Analytics — Full analytics explanation.
- Bot Detection Limits — What bots can and cannot be caught.