Skip to main content
Environments That Use a Different Domain
Language

Caveats

Important limitations and considerations when using cside.

Environments That Use a Different Domain

Staging environment

For cside to accurately and safely license our edge infrastructure, we use the referrer header in the requests to determine if the request is coming from a licensed customer. This approach may come with some caveats.

For example, if you use a staging environment, cside will not be able to accurately license the edge infrastructure for the scripts. This is because the referrer header will (often) be a different domain. This is often seen for preview/staging URLs that use a dynamically generated domain, like Vercel, Netlify, and other platforms.

Local environment

We have added some detection mechanisms to the web script to help with local environments, such as localhost, 127.0.0.1, ::1 and other cases to automatically disable the web script in those environments. If you do not want cside to run in the local environment, you can conditionally render the cside web script.

Cross-Origin Iframes

Browsers enforce the same-origin policy, which prevents a script running on your top-level page from reading or interacting with the contents of an iframe loaded from a different origin. Because of this, the cside script on your main page cannot see or monitor the DOM inside a cross-origin iframe.

If you embed an iframe that you own and you want cside to monitor what happens inside it, add the cside script to the document that loads inside the iframe. The script then runs in the iframe’s own context and can monitor that DOM directly, just as it does on your top-level page.

Only works for iframes you control

You can only add the cside script to iframes whose content you own and can modify. cside cannot monitor third-party iframes (such as embedded payment forms, ads, or widgets served from another origin), because you cannot inject a script into a document you do not control.

This is not a compliance gap. What happens inside a third-party iframe is not part of your store’s PCI DSS scope, and it cannot be. You do not control the code running in that document, so its contents fall outside your compliance boundary by definition. The party that serves the iframe is responsible for what runs inside it.

The relevant threat is different: a malicious script injecting an iframe into your page. That injection happens in your own page’s context, and cside can detect it. Monitoring the contents of a legitimate third-party iframe and catching an unauthorized iframe being injected into your page are two separate things, and only the latter is within cside’s reach.

Inline Scripts

cside currently does not monitor inline scripts. We plan to add support for monitoring inline scripts in the future. We recommend that you use the src attribute to load your scripts, instead of using inline. But we understand that this may not always be possible.

Was this page helpful?