Caveats
Known limitations when running cside, covering staging and local environments, cross-origin iframes, and how inline scripts are handled.
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
The web script does not work on local environments. cside licenses every script request by its Referer header, and hosts such as localhost, 127.0.0.1, ::1, and LAN addresses have no registrable domain to check, so the edge rejects the request with HTTP 400. Nothing is monitored and the script does not run. If you do not want that request to be made at all during local development, conditionally render the cside script tag. See Testing cside on staging for the recommended setup.
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.
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.
Thanks for your feedback!