Rate Limiting Your Shopify Storefront Against Bots

Rate limiting is the quiet workhorse of bot defense. It doesn't try to identify who a visitor is; it simply caps how fast anyone can act. Done right, it stops card testing, credential stuffing, scraping, and inventory hoarding while a real shopper never notices. Done wrong, it locks out legitimate customers during a flash sale. The difference is entirely in the thresholds and the response you choose.

What rate limiting actually protects

Almost every automated attack depends on volume:

• Card testing fires many small authorizations per minute.
• Credential stuffing submits thousands of login attempts.
• Scraping requests hundreds of product pages.
• Checkout/inventory bots hammer add-to-cart to hoard limited stock.

A human can't do any of these fast enough to matter. Rate limiting turns that asymmetry into a defense: set the ceiling above human speed and below bot speed.

Choosing the dimension: per-IP vs per-session

Per-IP limits cap requests from a single address over a window. They're simple and catch naive bots, but two failure modes matter:

• Shared IPs. Corporate offices, universities, and carrier-grade NAT put many real users behind one address. Too tight a per-IP limit blocks a whole building.
• Rotating IPs. Attackers on residential proxies spread requests across thousands of addresses, so no single IP ever trips the limit.

Per-session limits track a browser session or fingerprint instead of an IP. They handle shared IPs gracefully and catch attackers who rotate addresses but reuse a session. The tradeoff is that sessions can be discarded and regenerated.

Best control. Use both. Per-IP limits catch crude volume; per-session and per-fingerprint limits catch rotators. Layer them so an attacker has to defeat both dimensions at once.

Burst vs sustained limits

A single fixed threshold is a blunt instrument. Real traffic is bursty — a shopper opens several tabs, a page fires multiple requests on load. Model two windows:

• Burst limit. A short window (say 10 seconds) with a higher ceiling, absorbing legitimate spikes like a page loading its assets.
• Sustained limit. A longer window (say 1–5 minutes) with a lower average rate, catching bots that pace themselves under the burst threshold but never stop.

Illustratively: allow up to 30 requests in any 10-second burst, but no more than 300 in any 5 minutes. A human easily fits inside both; a scraper pacing at 5 requests/second stays under the burst but blows the sustained window fast.

Track the most-abused endpoints separately. Login, checkout, add-to-cart, and product .json endpoints deserve tighter limits than browsing your homepage.

Challenge vs block

When a limit trips, you have two responses, and choosing correctly is what prevents lost sales:

• Challenge. Present a CAPTCHA or interstitial. A real user solves it and continues; a bot usually can't. Use this when there's meaningful risk of a false positive — shared IPs, sale-day surges, moderately elevated velocity.
• Block. Deny outright. Reserve for high-confidence bot signals: a datacenter ASN, a known-bad User-Agent, or velocity far beyond any human threshold.

A good policy escalates: first challenge, then throttle (slow responses), then block on continued abuse. Never open with a hard block on ambiguous signals — that's how you lose customers.

Combining rate limits with identity signals

Rate limiting is far more precise when paired with who the visitor appears to be. The same velocity means different things from different sources:

• Datacenter IP + high velocity → block. No real shopper is here.
• Residential IP + high velocity + no interaction → challenge. Possibly a proxy bot.
• Residential IP + high velocity + real browsing → allow, or raise the ceiling. Likely a genuine power user.

This is where ASN and reputation data multiply the value of raw counting. Shieldy Fraud Filter classifies traffic by ASN — datacenter, VPN, proxy, Tor — and blocks the abusive categories at the network and checkout layer via Shopify Functions, so your velocity thresholds can stay generous for real shoppers while still stopping the automated volume behind flagged networks.

Avoiding false positives

The whole point is to be invisible to real customers. Guard against over-blocking:

• Set thresholds from real data. Measure your actual human traffic first, then set limits well above the 99th percentile of normal behavior.
• Account for flash sales. Legitimate traffic can spike 10x during a drop. Raise limits or shift to challenges during known events instead of blocking.
• Respect shared IPs. Lean on per-session limits behind NAT so one address doesn't lock out a crowd.
• Allowlist good bots. Verified Googlebot, Bingbot, your monitors, and payment/webhook callbacks should never be throttled — verify by IP range or reverse DNS, not UA.
• Prefer challenge on ambiguity. When unsure, challenge. A solved CAPTCHA costs a bot everything and a real user five seconds.
• Monitor the block log. If real customers appear in it, your thresholds are too tight — loosen them.

Putting it together

A resilient setup layers per-IP and per-session limits, separates burst from sustained windows, applies tighter caps to sensitive endpoints, escalates challenge-before-block, and combines all of it with ASN and reputation signals so velocity is interpreted in context. The result is a storefront that shrugs off card testers, stuffers, and scrapers while your real customers never hit a wall.

Want rate-limiting and ASN filtering working together without building it yourself? Start with Shieldy Fraud Filter — see the pricing page to match a plan to your traffic.