Bring Your Own Security
Overview
You can use Storefront Hosting with your own edge layer in front. This enables you to make use of the web application firewall (WAF), bot management, rate limiting, request logging, or incident response tooling you already operate.
Storefront Hosting supports this pattern. Your edge sits in front of SCAYLE and inspects traffic first; SCAYLE's own edge remains in place behind yours.
What SCAYLE's Security Rules see depends on your edge.
- Cloudflare (orange-to-orange): SCAYLE sees each visitor's real IP address and country. Do not restrict SCAYLE's Security Rules to Cloudflare's IP ranges - that would block your shoppers.
- Akamai or Fastly: all traffic reaches SCAYLE from your edge's IPs, so IP-based and country-based rules in SCAYLE's Firewall cannot target individual visitors. The recommended use is to allow traffic only from your edge's IP ranges and block everything else, so visitors cannot bypass your edge. See Prevent the bypass.
With any edge in front, do not use SCAYLE's Bot score rules - once traffic has passed through another edge, most real visitors are scored as likely automated.
When to use it
Bring Your Own Security is intended for teams that:
- Already operate a WAF, bot management, or similar edge security tooling at their perimeter.
- Want to apply their own security policies (rules, challenges, rate limits) before traffic reaches SCAYLE.
- Need to centralize logging and incident response on their existing security stack.
If you do not operate your own edge, use the built-in SCAYLE Firewall and Rate Limiting instead. See Firewall for the built-in options.
How it works
The setup is the same across all three supported edges: Cloudflare, Akamai, and Fastly.
Traffic flow:
- A visitor requests
shop.yourbrand.com. - The request arrives at your edge. Your security rules apply here (your WAF, your bot rules, your rate limits).
- What passes your rules is forwarded to the SCAYLE Domain for your environment.
- The request passes through SCAYLE's edge and reaches your Storefront Hosting application.
SCAYLE Panel setup is the same as any other custom hostname. When you add a custom hostname in Storefront Hosting (see Domains), the SCAYLE Panel displays a SCAYLE Domain for your environment on the Domains page - something like yourshop.sf.scayle.shop. In your edge, you forward traffic for your public hostname to that SCAYLE Domain.
Cloudflare in front
Cloudflare in front is also called orange-to-orange (O2O), named after Cloudflare's "orange cloud" icon that marks DNS records as proxied through its network. In your Cloudflare account, you add a DNS record for your public hostname as a CNAME pointing at the SCAYLE Domain, with Cloudflare's proxy toggle on (the orange cloud icon). If you register an intermediate hostname (Pattern B), point the CNAME there instead. See Which hostname to register.
With Cloudflare in front, requests reach SCAYLE with each visitor's real IP address and country, so SCAYLE's IP-based and country-based Security Rules keep working per visitor. Do not restrict SCAYLE's Security Rules to Cloudflare's IP ranges.
Akamai in front
In Akamai, you configure a property that forwards traffic to the SCAYLE Domain. See the "Which hostname to register" section below for how to decide what to register on SCAYLE's side.
Fastly in front
In Fastly, you configure a service that forwards traffic to the SCAYLE Domain. The same registration patterns apply.
Other edges (non-Cloudflare, non-Akamai, non-Fastly) are not supported today. Reach out to your SCAYLE Account Manager before putting one in front of your Storefront Hosting.
Which hostname to register
Two registration patterns are supported. Both work the same way on SCAYLE's side; they differ in whether the hostname SCAYLE knows is the public one or an internal one.
Pattern A: register the public hostname.
Register the public hostname (the one visitors type) as the custom hostname in Storefront Hosting. Your edge forwards traffic to the SCAYLE Domain with the public hostname as the Host header.
Example with public hostname www.example.com:
- Register
www.example.comas the Storefront Hosting custom hostname. - Traffic flow:
www.example.com→ your edge → SCAYLE Domain (Host:www.example.com) → Storefront Hosting.
Pattern B: register an intermediate hostname.
Register a separate internal hostname on SCAYLE's side. Your edge forwards traffic to that intermediate hostname, which resolves to the SCAYLE Domain. In Pattern B your edge must rewrite the Host header to the intermediate hostname before forwarding, otherwise SCAYLE will not match the request to the registered custom hostname.
Example with public hostname www.example.com and intermediate prd.example.com:
- Register
prd.example.comas the Storefront Hosting custom hostname. - In your edge, rewrite the Host header from
www.example.comtoprd.example.comon forward. - Traffic flow:
www.example.com→ your edge →prd.example.com(Host:prd.example.com) → Storefront Hosting.
Pattern A is simpler and matches what most edges do by default. Pattern B adds a layer of indirection and can be useful if you want the hostname registered on SCAYLE's side to stay distinct from the public-facing hostname.
Pattern B has not been broadly tested with all edges yet. If you plan to use it, confirm with your SCAYLE Account Manager and validate the Host header rewrite in a non-live environment first.
Prevent the bypass (Akamai and Fastly)
With Akamai or Fastly in front, SCAYLE's Firewall should only accept traffic that came through your edge. Two SCAYLE Security Rules are enough:
- A Skip rule that matches your edge's published IP ranges (Match type: IP / CIDR, Action: Skip).
- A Block rule that matches all other traffic (Match type: IP / CIDR, Entries:
0.0.0.0/0and::/0, Action: Block), ordered after the Skip rule.
The Skip rule lets legitimate traffic from your edge through; the catch-all Block rule stops anything that hits the SCAYLE Domain directly, bypassing your edge. Keep the Skip rule's IP list in sync whenever your edge provider updates its ranges.
Do not set this up with Cloudflare in front. With Cloudflare orange-to-orange, requests reach SCAYLE with each visitor's own IP address, not with Cloudflare's. A Skip rule for Cloudflare's IP ranges would match almost no traffic, and the Block rule would then block your shoppers. IP-based bypass protection is not available for Cloudflare orange-to-orange today; contact your SCAYLE Account Manager if you need it.
Apex domains (Cloudflare O2O)
The guidance below applies to Cloudflare O2O. Cloudflare O2O is CNAME-based, so a custom hostname that resolves directly to an apex domain (example.com) using A or ALIAS records is not eligible out of the box.
If your custom hostname is an apex domain and your edge is Cloudflare:
- Move the authoritative DNS for the domain to your Cloudflare account.
- Use Cloudflare's CNAME flattening at the apex to produce a proxied, CNAME-equivalent setup.
The result is a hostname that answers at the apex but, from SCAYLE's point of view, behaves as a CNAME to the SCAYLE Domain.
Akamai and Fastly handle apex domains differently (for example, Akamai's Edge Hostname with DNS delegation, or Fastly's A-record setup pointing at Fastly IPs). Follow your edge provider's guidance for apex domains, then confirm the resulting setup with your SCAYLE Account Manager before going live.
Shared responsibility
With your own edge in front:
| Layer | What it handles |
|---|---|
| Your edge | All front-line security filtering targeting individual visitors: WAF, bot management, rate limiting by client IP or country, logging, incident response. |
| SCAYLE edge | Continues to serve traffic to your Storefront Hosting application, and SCAYLE's Security Rules still apply. With Cloudflare in front, they see each visitor's real IP address and country. With Akamai or Fastly in front, they see your edge as the source of all traffic - one or more edge IPs, with countries reflecting the edge PoP locations rather than visitor countries - so the recommended use is to allow traffic only from your edge's IPs and block everything else. Bot score rules do not work meaningfully with any edge in front. |
| SCAYLE APIs and services | Always behind SCAYLE's own protection. Running your own edge does not change this. |
Known limitations
The following SCAYLE-side behaviors apply when your own edge is in front:
- Client-IP attribution with Akamai and Fastly. SCAYLE does not recover real client IPs from upstream edge headers (such as
True-Client-IPorX-Forwarded-For) today. With Akamai or Fastly in front, SCAYLE sees your edge as the client, so any security feature that depends on the real client IP (such as blocking by country or by individual IP) has to run at your edge. With Cloudflare orange-to-orange, SCAYLE sees each visitor's real IP address without relying on these headers. - Cloudflare O2O detection. SCAYLE does not act on the
cf-connecting-o2o: 1header today. Traffic arriving via Cloudflare O2O is treated the same as any other traffic by SCAYLE's detection and logging. __cf_bmcookie interaction. The__cf_bmcookie set by SCAYLE's Cloudflare zone causes cache bypass in your visitor-facing Cloudflare zone, a documented Cloudflare quirk. SCAYLE does not provide a workaround today. Contact your SCAYLE Account Manager if this is affecting your cache hit rate.- Direct-to-origin bypass. Patterns that route traffic from your edge directly to a SCAYLE origin, bypassing SCAYLE's own edge, are not supported. Contact your SCAYLE Account Manager if your setup follows this pattern.
Related
- Firewall - the built-in Security Rules. With Akamai or Fastly in front, use them to allow only your edge's IP ranges (see Prevent the bypass).
- Rate Limiting - SCAYLE-side rate limiting.
- Domains - how to set up the SCAYLE custom hostname your edge points at.