Scans now read Checkout on a stock WooCommerce store using a one-product cart held in memory only. The first such scan may flag server-added headers: review and accept them. Add Payment Method still needs a signed-in customer, which is not an error.<\/p>","1.0.7":"
Security hardening: the script inventory now matches what browsers actually load.<\/p>","1.0.6":"
Translation-ready throughout.<\/p>","1.0.5":"
Listing title and tags for WordPress.org, plus an optional review request on the plugin's own screen.<\/p>","1.0.4":"
WordPress core scripts are now recognised on installs with a non-default wp-includes or wp-admin location.<\/p>","1.0.3":"
Scripts whose type attribute carries a charset parameter are now inventoried: run a scan after updating. If you use a custom payment-page path with accented or percent-encoded characters, enter it again on the Settings tab.<\/p>","1.0.0":"
Initial release of Dragon Checkout Guard.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.gif":{"filename":"icon-128x128.gif","revision":3711770,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.gif":{"filename":"icon-256x256.gif","revision":3711770,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3711662,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3711662,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.4","1.0.5","1.0.6","1.0.7","1.0.8"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3711662,"resolution":"1","location":"assets","locale":"","width":1560,"height":1071},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3711662,"resolution":"2","location":"assets","locale":"","width":1560,"height":916},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3711662,"resolution":"3","location":"assets","locale":"","width":1560,"height":974},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3711662,"resolution":"4","location":"assets","locale":"","width":1560,"height":1168}},"screenshots":{"1":"The script inventory: every script seen on your payment pages, with the provider recognised, a warning pill on anything that can inject more scripts, and one-click authorisation.","2":"The printable payment page script integrity record: assessment context, the authorised scripts and the ones still awaiting review, and the 11.6.1 check record, ready to hand to an assessor.","3":"Response header baselines per payment page, so a change to Content-Security-Policy or framing controls is flagged instead of going unnoticed.","4":"The assessment guide: answer three plain questions and it shows which PCI SSC FAQ 1588 route your answers point to and the records that route asks for."}},"plugin_section":[],"plugin_tags":[275069,237432,282532,265161,286],"plugin_category":[45,54],"plugin_contributors":[276960],"plugin_business_model":[],"class_list":["post-372691","plugin","type-plugin","status-publish","hentry","plugin_tags-card-skimming","plugin_tags-checkout-security","plugin_tags-payment-page","plugin_tags-pci-dss","plugin_tags-woocommerce","plugin_category-ecommerce","plugin_category-security-and-spam-protection","plugin_contributors-dragoncoreltd","plugin_committers-dragoncoreltd"],"banners":{"banner":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/banner-772x250.png?rev=3711662","banner_2x":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/banner-1544x500.png?rev=3711662","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/icon-128x128.gif?rev=3711770","icon_2x":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/icon-256x256.gif?rev=3711770","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/screenshot-1.png?rev=3711662","caption":"The script inventory: every script seen on your payment pages, with the provider recognised, a warning pill on anything that can inject more scripts, and one-click authorisation."},{"src":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/screenshot-2.png?rev=3711662","caption":"The printable payment page script integrity record: assessment context, the authorised scripts and the ones still awaiting review, and the 11.6.1 check record, ready to hand to an assessor."},{"src":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/screenshot-3.png?rev=3711662","caption":"Response header baselines per payment page, so a change to Content-Security-Policy or framing controls is flagged instead of going unnoticed."},{"src":"https:\/\/ps.w.org\/dragon-checkout-guard\/assets\/screenshot-4.png?rev=3711662","caption":"The assessment guide: answer three plain questions and it shows which PCI SSC FAQ 1588 route your answers point to and the records that route asks for."}],"raw_content":"\n
Nearly every WooCommerce store embeds its gateway's card fields in an iframe:\nStripe, WooPayments, PayPal, Braintree or Adyen. Since 31 March 2025, SAQ A\ncarries an eligibility criterion that such a merchant has confirmed its site is\nnot susceptible to attacks from scripts, and PCI SSC FAQ 1588 (February 2025)\nsets out the two ways to confirm it: apply techniques such as those in\nrequirements 6.4.3 and 11.6.1 to your own page, or hold written confirmation\nfrom the PCI DSS validated provider that its embedded form includes script\nattack protections when implemented to the provider's instructions. That second\nroute is not available from every provider, which leaves the first: an inventory\nof the scripts on the page around the iframe, a justification for each one, and\na check that they have not changed.<\/p>\n\n
The iframe is the provider's. The page it sits in is yours, and a script\ninjected into that page is what e-skimming (the Magecart style of attack) uses\nto read a shopper's details before the iframe ever sees them. Dragon Checkout\nGuard is the record of what runs on that page.<\/p>\n\n
It records, on your own WooCommerce checkout, order-pay, add-payment-method and\n(optionally) cart pages:<\/p>\n\n
<script><\/code> elements\n(external and inline), module preloads and import maps, with who added\neach one (event-handler attributes such as onclick<\/code> and the documents in<\/li>\n<\/ul>\n\n<<\/p>\n\n
iframe srcdoc> are not inventoried),\n* an authorisation entry per script: owner, business purpose, justification,\n provider and integrity method,\n* a content hash per script, rechecked weekly, so a change is flagged,\n* a baseline of each page's security response headers, with drift flagged,\n* an evidence trail you can export for an assessor.<\/p>\n\n
It runs on your own server with no account, no JavaScript tag to a third party\nand no pageview cap.<\/p>\n\n
What it does<\/h4>\n\n\n- Script inventory<\/strong> - Every
<script><\/code> 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<\/code>\/.mjs<\/code> path, a string containing HTML markup or \/\/<\/code>, 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.<\/li>\n- Authorisation workflow<\/strong> - 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.<\/li>\n
- Weekly tamper check<\/strong> - 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.<\/li>\n
- Response-header baseline<\/strong> - 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 the scan could not put a product in the cart for) is baselined from shoppers' own pageviews, which see only the headers WordPress itself sets. A header that appears after the baseline is flagged as added.<\/li>\n
- Recognised payment providers<\/strong> - 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.<\/li>\n
- Assessment guide<\/strong> - 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\".<\/li>\n
- Exports for an assessor<\/strong> - Inventory CSV, 11.6.1 check-record CSV and a printable \"Payment page script integrity record\", plus the same data from WP-CLI.<\/li>\n
- Site Health tests<\/strong> - Whether the weekly check has run, whether any script is unauthorised, and whether any header baseline is outstanding.<\/li>\n
- Optional browser collector<\/strong> - 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.<\/li>\n<\/ul>\n\n
What it is not<\/h4>\n\n
Dragon Checkout Guard is not a Qualified Security Assessor, not a\ncertification service, and not a substitute for your own PCI DSS assessment.\nIt never claims a site \"is compliant\" or \"is certified\", and it does not\ndetermine which SAQ you complete: it produces evidence supporting the\nassessment you or your assessor make. Your acquirer or QSA settles your SAQ\neligibility.<\/p>\n\n
It also cannot see inside your gateway's iframe. It is not meant to: that\ndocument is served by the provider from its own origin and is covered by the\nprovider's own PCI DSS validation. The page around it is the merchant's, and\nthat is what this plugin inventories.<\/p>\n\n
External services<\/h3>\n\n
This plugin has no service of its own. It makes no connection to Dragon Core, needs no account and sends no telemetry.<\/p>\n\n
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<\/code>, a gateway SDK, Google Tag Manager, or whatever else your payment pages reference.<\/p>\n\n\n- When: during the weekly check, and when you start a scan yourself (\"Scan now\", or
wp dragon-checkout-guard scan<\/code>). At most 200 downloads a day, 2 MB per file, HTTPS only.<\/li>\n- 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)<\/code>. No cookies are sent, and nothing about your site, its settings, its customers or its orders.<\/li>\n- 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.<\/li>\n<\/ul>\n\n
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.<\/p>\n\n
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.<\/p>\n\n
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.<\/p>\n\n
Credits<\/h3>\n\n
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.<\/p>\n\n
Privacy Policy<\/h3>\n\n
Dragon Checkout Guard records, in your own WordPress database:<\/p>\n\n