Script Governance
Script Governance gives you full visibility and a documented authorization trail over every JavaScript file that loads on your production checkout pages. It is built to support the client-side security requirements introduced with PCI DSS v4.0, in particular the obligation to maintain an inventory of all scripts on payment pages, record a written justification for each, and continuously monitor them for change.
The feature lives in the SCAYLE Panel under Hosting > Security and is powered by Cloudflare threat intelligence, normalized for the SCAYLE interface.
PCI DSS v4.0 requirements 6.4.3 (manage and authorize all payment-page scripts, each with a documented justification) and 11.6.1 (detect and alert on changes to payment-page scripts) are the standards this feature is designed to help you address. Script Governance does not by itself make a shop PCI compliant. It provides the inventory, monitoring, and authorization record that your compliance process relies on. See the References section for the official PCI SSC guidance.
How it works
SCAYLE automatically scans your production checkout pages and builds a live catalog of every script it detects. The catalog is refreshed every 24 hours, so newly introduced scripts surface automatically without any manual import. Each script is analyzed for malicious behavior, assigned a threat level, and tracked across versions so you can see when its content changes.
There is nothing to install or enable. Monitoring runs continuously in the background for every shop on Storefront Hosting.
Access and availability
- Who can access it: Any Panel user with access to Storefront Hosting and the View Scripts (
storefront-platform__scripts__read) Permission can open the Security area and view the script catalog.- For the authorization workflow, the Authorize scripts (
storefront-platform__scripts__edit) permission is needed.
- For the authorization workflow, the Authorize scripts (
- Environments: Script Governance covers production environments only. Scripts loaded in sandbox or preview deployments are not monitored.
- Where to find it: SCAYLE Panel > Hosting > Security.
The deployment selector in the top right corner (labeled Latest) controls which deployment's detected scripts are shown.
Monitored Scripts Overview
The Security page opens on the Monitored Scripts list, a single filterable table of every script detected on your checkout pages. The count next to the heading (for example, 25+) reflects how many scripts are currently cataloged.
Filters
Filter chips at the top of the list let you narrow the catalog by three independent dimensions:
| Filter group | Values |
|---|---|
| Threat level | Safe, Malicious |
| Origin | 1st Party, 3rd Party |
| Authorization | Authorized, Pending |
Filtering by Malicious and Pending together is the fastest way to find scripts that need immediate attention.
Columns
| Column | Description |
|---|---|
| Script URL | The full URL of the detected script, with its host shown beneath. |
| Threat Level | The result of automated analysis: Safe or Malicious. |
| Origin | Whether the script is served from your own domain (1st Party) or an external one (3rd Party). |
| Authorization | The review state: Authorized or Pending. |
| Last Seen | The date the script was most recently observed on a checkout page. |
Each row also exposes quick actions: an eye icon to open the script's detail view, and, for any script still Pending, a shield icon to authorize it directly from the list.
Script Details Page
Selecting a script (via the eye icon, or by clicking the row) opens Script Details, the full record used for review and audit. Use Back to Scripts to return to the catalog.
The header repeats the script URL and host, along with its current badges (threat level, origin, and authorization state). Below it, the page is organized into the following sections.
Threat summary
A status banner gives the headline verdict of the most recent scan, for example, "No threats detected. The last scan passed with no malicious signals across the analysis engines."
Malicious Code Analysis
Shows the script's Risk level as a percentage, where 0% indicates no malicious signal. This reflects the highest signal found across known attack patterns. Individual pattern checks are listed beneath it:
- Magecart
- Malware
- Crypto mining
Threat Intelligence
Reputation and provenance signals for the script:
- URL match: whether the URL appears in known threat databases (for example:
Not present). - Domain reputation: the standing of the serving domain (for example:
Trusted). - First seen: SCAYLE's first observation of the script.
Script metadata
- Last Seen and First Seen timestamps.
- Seen on Host: the checkout host the script was loaded on.
- Origin: 1st or 3rd party.
- Script URL: the full URL, with copy and open in new tab actions.
Version history
A chronological list of every version of the script SCAYLE has observed, so you can detect when a script's content changes. This is a core part of continuous monitoring. Each entry records:
- Seen at: the timestamp of the observed version (the active version is tagged Current).
- Malicious %: the risk level recorded for that version.
- Hash: the content hash of that version.
Review and authorization workflow
Authorization is the mechanism that turns the script catalog into a defensible compliance record. Every script is in one of two authorization states:
- Pending: detected but not yet reviewed and approved.
- Authorized: reviewed and approved, with a justification on record.
Authorizing a script
Open a script's detail page, or use the shield icon in the list. A Pending script shows a Not Authorized panel explaining that the script has not yet been reviewed, with an Authorize Script action. Authorizing a script requires a documented justification describing its business or technical purpose, which is stored as part of the compliance record.
Once authorized, the Authorized panel records:
- Authorized by: the user, or Scayle System for automatic authorizations, who approved the script.
- On: the date and time of authorization.
- Justification: the documented reason the script is permitted on payment pages.
- Future versions: authorization carries over automatically to new versions of the same script.
This record provides the "who authorized it, when, and why" trail required for auditing, and it is retained and visible in the Panel.
Revoking authorization
An authorized script can be reviewed again at any time via Revoke Authorization, which returns it to a pending, unauthorized state. Use this, for example, if a justification no longer holds or if a script's content has changed in a way that warrants a fresh review.
Recommended routine: To stay aligned with PCI DSS v4.0, authorized users should review the Monitored Scripts list regularly, confirming that every active script is recognized and authorized with a current justification, and investigating any script flagged with a Malicious threat level or appearing as 3rd Party and Pending.
References
- PCI Security Standards Council, "Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1" (information supplement, March 2025): https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming
- PCI DSS Requirement 6.4.3: all payment-page scripts loaded and executed in the consumer's browser must be managed so that each script is authorized, the integrity of each script is assured, and an inventory of all scripts is maintained with a written justification for why each is necessary.
- PCI DSS Requirement 11.6.1: a change- and tamper-detection mechanism must alert personnel to unauthorized modification, including indicators of compromise, changes, additions, and deletions, to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer's browser.
