There is no Shopify firewall: the four layers you can actually block traffic at

A merchant forwards you a support thread. Someone is scraping their entire catalog every night, or a competitor is clicking their ads from a datacenter, or a run of fraudulent orders keeps arriving from the same network. The ask is simple and reasonable: block them.

On almost any other stack this is a solved problem. Put a WAF in front, write a rule, done. On Shopify, the first hour of work is discovering that the layer you would put the rule at does not exist for you. This post is the map: the four layers where blocking on Shopify is genuinely possible, what each one can and cannot enforce, and how to pick.

Layer 0: the edge, and why it's closed

Every request to a Shopify storefront hits Shopify's CDN first. Shopify sees the IP, the ASN, the headers, the TLS fingerprint. It runs its own bot detection there. You get none of it, and there is no merchant-facing rule engine at this layer. No IP allowlist, no rate limit configuration, no WAF.

The natural next thought is to bring your own edge. It does not work: pointing a domain at Shopify with Cloudflare's proxy enabled produces the error Your domain has a Cloudflare Proxy, which is not supported by Shopify. Records have to stay DNS-only, on the grey cloud.

Accept layer 0 as closed and the rest of the design space gets clearer, because everything below is a compensation for not having it.

Layer 1: the storefront, via an app embed

This is the earliest point you can run your own code. A theme app extension with an app embed block targeting head injects a script on every storefront page without the merchant editing theme files. That script asks your own service, which does see the connection, whether this visitor is allowed, and acts on the answer.

1{% comment %}2  An app embed with "target": "head" in its schema loads on every3  storefront page. It carries no secrets: the script only needs the4  shop domain and a public endpoint.5{% endcomment %}6 7<script8  src="{{ 'blocker.js' | asset_url }}"9  data-shop="{{ shop.permanent_domain }}"10  data-api="https://your-decision-service.example"11  defer12></script>

Be precise about what this can and cannot claim. It runs in the browser, so the HTML has already been delivered before the decision returns. It stops a human from using the store; it does not stop a raw HTTP client from reading it. Anyone quoting you a storefront-layer product as protection against curl is overselling.

Two engineering constraints dominate this layer, and both are non-obvious until you ship:

• It must fail open. Your decision service now sits in the critical path of every page load on someone's store. If it is slow or down and the script fails closed, you have taken the storefront offline. The correct default is a short timeout after which every visitor is allowed through. Occasionally letting a bad visitor past is strictly better than blocking real customers.
• It must be fast and small. A decision that takes 400ms is a 400ms delay on a merchant's revenue-generating pages. Sub-50ms decisions and a script measured in single-digit kilobytes are the bar, which in practice means edge-cached lookups rather than a database round trip per visitor.

Layer 2: checkout, via Shopify Functions

The Cart and Checkout Validation Function API is the only server-side way to validate a checkout, and it covers express checkouts too: Shop Pay, PayPal, Google Pay, Apple Pay. It is genuinely authoritative. A visitor cannot skip it by disabling JavaScript.

The catch is what it can see. The function input carries the cart, the buyerJourney step, buyer identity, and cart attributes. There is no IP, no ASN, no user agent, no country of connection. So Functions enforce rules about what is being bought and by whom, never about where the request came from.

Worth knowing: a store can activate at most 25 validation functions, and errors surface on the Storefront API's cart object as well as in checkout, so your cart template can show them before the shopper gets that far.

Layer 3: after the order exists

Once an order is placed the network data reappears. Order.clientIp on the Admin API returns the IP it was placed from (scope: read_orders), Shopify's built-in fraud analysis scores the order, and Shopify Flow can act on that automatically:

1query RiskReview {2  order(id: "gid://shopify/Order/1234567890") {3    name4    clientIp5    customerJourneySummary {6      momentsCount7    }8  }9}

This layer is the right home for chargeback evidence, manual review queues, and auto-cancelling high-risk orders. It is the wrong home for anything you needed to prevent, because the order already exists and, for a limited-stock drop, the inventory is already committed. Scrapers never reach this layer at all, since they never check out.

Picking a layer from the actual problem

The mistake is starting from the tool. Start from what is going wrong, because each problem has essentially one correct layer:

Note the last two rows. A meaningful share of "block a country" requests are really "stop accepting orders from there," and Shopify does that natively, for free, deterministically. Check whether Markets solves it before anyone installs anything.

If you have identified your row and want the click-by-click version, we have step-by-step guides for blocking a country, blocking an IP address, and blocking VPN and proxy traffic. The rest of this post is the reasoning underneath them.

If you build layer 1 yourself

It is a tempting weekend project and it is not one. The app embed is the easy part. What sits behind it is a small distributed system:

1. Live reputation data. VPN, proxy, and datacenter ranges change constantly. A static IP list is stale within weeks, and stale lists are how legitimate customers get blocked.
2. A decision service inside a page-load budget. Cached lookups at the edge, not a database query per visitor.
3. A fail-open path with a hard timeout. Non-negotiable. Your outage must not become the merchant's outage.
4. Verified-crawler exemptions. Reverse-DNS confirmed, so search engines and the AI crawlers you want indexing the store get through.
5. Privacy-conscious logging. Raw visitor IPs in a table is a GDPR liability. Hashing with a rotating daily salt gives you the debugging value without keeping identifiable data.

That list is the honest scope, and it is why this category exists as products rather than snippets. Every item on it is infrastructure you would be operating forever, on someone else's revenue-critical storefront.

What layer 1 looks like when it's built for you

If you would rather not run that infrastructure, Cordon is a Shopify app built specifically around this layer model. It is worth walking through concretely, because it maps one-to-one onto the five requirements above and shows what "done properly" costs in practice.

On the rule side it covers the full set this post has been describing: country blocking across 200+ countries, individual IPs and CIDR ranges, whole ASNs, and datacenter networks like AWS, Alibaba, Tencent, and Huawei Cloud where scrapers actually originate. Bot detection works on user-agent analysis, headless-browser markers left by Puppeteer, Selenium and Playwright, and request-velocity patterns that no human produces. There are one-click presets for the common cases, and a free tier to try the mechanism on a real store before committing.

The reporting side matters more than it sounds. When a merchant asks why a particular customer could not reach the store, you need to answer in one look rather than by reasoning about which of nine rules might have fired. The dashboard names the rule behind every decision, which is also how you tell an over-broad rule from a working one:

For the merchant-side walkthrough of each rule type there are step-by-step guides for blocking VPN and proxy traffic, blocking a country, and blocking an IP address. If you are weighing options, Cordon also publishes a comparison against Blockify and Blocky, which is a faster read than installing three apps.

If you want to see what layer-1 traffic actually looks like on a real store rather than in the abstract, there is a logged breakdown of a store where 21,840 of 33,700 visits in 22 hours came from one hosting ASN. It is a useful illustration of why the country column misleads you here: every one of those requests reported as ordinary traffic from Singapore, because the network operator is the signal and Shopify does not surface it.

The part worth keeping either way is the map. Shopify's constraints are not arbitrary; they follow from a CDN-cached storefront you do not own. Once you can name which layer a request is at and what that layer is allowed to know, most of these questions answer themselves, including the ones about why the visitor's IP isn't in Liquid and why localization.country isn't geolocation.