Dragon Checkout Guard – PCI DSS Compliance & Card Skimming Detection for WooCommerce

Nearly every WooCommerce store embeds its gateway’s card fields in an iframe:
Stripe, WooPayments, PayPal, Braintree or Adyen. Since 31 March 2025, SAQ A
carries an eligibility criterion that such a merchant has confirmed its site is
not susceptible to attacks from scripts, and PCI SSC FAQ 1588 (February 2025)
sets out the two ways to confirm it: apply techniques such as those in
requirements 6.4.3 and 11.6.1 to your own page, or hold written confirmation
from the PCI DSS validated provider that its embedded form includes script
attack protections when implemented to the provider’s instructions. That second
route is not available from every provider, which leaves the first: an inventory
of the scripts on the page around the iframe, a justification for each one, and
a check that they have not changed.

The iframe is the provider’s. The page it sits in is yours, and a script
injected into that page is what e-skimming (the Magecart style of attack) uses
to read a shopper’s details before the iframe ever sees them. Dragon Checkout
Guard is the record of what runs on that page.

It records, on your own WooCommerce checkout, order-pay, add-payment-method and
(optionally) cart pages:

• an inventory of the scripts the page loads through <script> elements
  (external and inline), module preloads and import maps, with who added
  each one (event-handler attributes such as onclick and the documents in

<

iframe srcdoc> are not inventoried),
* an authorisation entry per script: owner, business purpose, justification,
provider and integrity method,
* a content hash per script, rechecked weekly, so a change is flagged,
* a baseline of each page’s security response headers, with drift flagged,
* an evidence trail you can export for an assessor.

It runs on your own server with no account, no JavaScript tag to a third party
and no pageview cap.

What it does

• Script inventory – Every <script> src and inline block seen on your payment pages, discovered from the rendered HTML (read with PHP’s HTML5 parser on PHP 8.4+, the way a browser reads it) and, optionally, from a real shopper’s browser. Inline blocks printed by WordPress are identified by handle and position, so a change to one is recorded as drift on the same row rather than appearing as a new script every time. A change counts when it alters the block’s code, the host of a URL it names, the rest of that URL, a relative .js/.mjs path, a string containing HTML markup or //, or a template literal; numbers, long token-like values (nonces, order keys, hashes) and other string values such as tracking ids and labels are ignored, so a rotating nonce never registers as drift.
• Authorisation workflow – Record a justification, owner, business purpose, provider and integrity method (Subresource Integrity, hash monitored by this plugin, vendor-managed, or not feasible with a justification) for every script that belongs on your payment pages.
• Weekly tamper check – A weekly WP-Cron scan, plus Scan now and WP-CLI. Every pending script is rehashed on each run, and a change that could not be written is reported as a failed scan rather than a clean one.
• Response-header baseline – Captures the security-relevant response headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, Referrer-Policy, Permissions-Policy, the Cross-Origin trio, X-Content-Type-Options, Cache-Control and the CSP reporting headers) exactly as a shopper’s browser receives them – read from each scan’s own ordinary request, so headers your web server or CDN adds are included – and flags drift from the accepted baseline, including a header that stops being sent. A page a scan cannot reach (Order Pay, or a checkout that redirects an empty cart) is baselined from shoppers’ own pageviews, which see only the headers WordPress itself sets.
• Recognised payment providers – A known-provider list fills in the provider, purpose and a suggested justification for the common gateways, and flags tag managers, analytics and chat widgets with a reviewer note. A script is recognised by where it is served from, or by the handle WordPress registered it under; an element id or name that only appears in the page itself is never trusted to name a provider.
• Assessment guide – A three-question self-check that maps how your site takes payment to the FAQ 1588 route your answers point at, and to the records that route asks for. Your answers appear in the printable report as “Assessment context”.
• Exports for an assessor – Inventory CSV, 11.6.1 check-record CSV and a printable “Payment page script integrity record”, plus the same data from WP-CLI.
• Site Health tests – Whether the weekly check has run, whether any script is unauthorised, and whether any header baseline is outstanding.
• Optional browser collector – On by default, it reports scripts that only exist once a real shopper’s page is running (for example one injected by a tag manager), as observations you confirm before they join the inventory.

What it is not

Dragon Checkout Guard is not a Qualified Security Assessor, not a
certification service, and not a substitute for your own PCI DSS assessment.
It never claims a site “is compliant” or “is certified”, and it does not
determine which SAQ you complete: it produces evidence supporting the
assessment you or your assessor make. Your acquirer or QSA settles your SAQ
eligibility.

It also cannot see inside your gateway’s iframe. It is not meant to: that
document is served by the provider from its own origin and is covered by the
provider’s own PCI DSS validation. The page around it is the merchant’s, and
that is what this plugin inventories.

External services

This plugin has no service of its own. It makes no connection to Dragon Core, needs no account and sends no telemetry.

It makes one kind of outbound request. To notice when a script on your payment pages changes, it takes a SHA-256 hash of each script file those pages load. A script served from your own site is read from disk. A script served from another host is downloaded from that host, because there is no other way to see its contents. Which hosts those are is decided by your own checkout, not by this plugin: js.stripe.com, a gateway SDK, Google Tag Manager, or whatever else your payment pages reference.

• When: during the weekly check, and when you start a scan yourself (“Scan now”, or wp dragon-checkout-guard scan). At most 200 downloads a day, 2 MB per file, HTTPS only.
• What is sent: a GET request for that public script URL, from your server’s IP address, with the user agent Mozilla/5.0 (compatible; DragonCheckoutGuard/<version>; +https://dragoncore.ltd/plugins/dragon-checkout-guard). No cookies are sent, and nothing about your site, its settings, its customers or its orders.
• Where: only hosts your payment pages already reference, which every shopper’s browser already contacts when it loads the page. Private, loopback, link-local and reserved addresses are refused.

Those hosts belong to the providers you chose for your shop, so their own terms and privacy policies apply, the same as they do to the scripts your checkout already loads from them.

The plugin also ships a list of recognised providers (Stripe, PayPal, Google Tag Manager and others). It is used only to label a script and suggest a justification for it. The plugin does not connect to any provider on that list unless your payment pages already load a script from it.

To read a payment page the way a shopper’s browser receives it, the plugin also requests that page from your own site. That request never leaves your server.

Credits

The WordPress.org listing icon is drawn with glyphs from Lucide (https://lucide.dev), ISC License. Copyright (c) for portions of Lucide are held by Cole Bemis 2013-2022 as part of Feather (https://feathericons.com, MIT License). All other copyright (c) for Lucide are held by Lucide Contributors 2022. The plugin itself does not include these icons.

Privacy Policy

Dragon Checkout Guard records, in your own WordPress database:

• Script details. The URL (or a content fingerprint, for an inline script)
  of every script seen on an in-scope page, its content hash, and who authorised
  or revoked it and when.
• Response headers. The security-relevant header values your payment pages
  are served with, as each scan’s own request receives them, and a diff
  whenever they change.
• Scan and authorisation events. A forensic log of discoveries, scans and
  authorisation actions, each attributed to the WordPress user who performed it,
  never to a site visitor.

None of this identifies a site visitor. The plugin’s tables have no IP
address, user-agent or session column. The optional browser collector, which
reports scripts a real shopper’s page ran, is rate-limited per address using a
salted hash of the address kept in a transient for two minutes; on sites without
a persistent object cache that transient lives in the options table for that
time. Nothing else about the visitor (browser, referrer and so on) is recorded,
and inline script previews are stored with sensitive values redacted. Pageviews
by a logged-in user are ignored for header baselines.

External requests: to notice when a script changes, the plugin downloads a
script your payment page already loads from another host and hashes the
contents; a script on your own site is read from disk. That request is a plain
HTTPS GET of a public URL: it carries no data about your site, its configuration
or its visitors. It never contacts Dragon Core or any other service of ours:
there is no account and no telemetry. See External services above.

Uninstalling the plugin keeps all of this data by default; tick Delete this
plugin’s tables, options and evidence when it is uninstalled on the Settings
tab first if you want it removed instead.

For more information, visit Dragon Core.