# Glossary > Short definitions of the client-side security and PCI DSS terms used in these docs, from Magecart and CSP to requirements 6.4.3 and 11.6.1. Source: https://docs.scriptmonitoring.com/glossary/ · Plan: All plans · Updated 2026-10-14 The terms these docs use, each in a sentence or two. Every definition links to a longer article on the Script Monitoring blog, and to the docs page that covers it in the product where there is one. ## Attacks ### Magecart A name for the criminal groups, and by extension the style of attack, that plant card-stealing JavaScript on online checkout pages. It started with attacks on Magento stores and is now used for browser-side card theft on any platform. [What is Magecart?](https://www.scriptmonitoring.com/blog/what-is-magecart/) ### Web skimming Stealing what a visitor types into a web page, such as card numbers or passwords, with code that runs in the visitor's browser. The data goes from the browser straight to the attacker, so nothing unusual reaches the merchant's servers. [What is web skimming?](https://www.scriptmonitoring.com/blog/what-is-web-skimming/) ### Formjacking A kind of web skimming in which a script attaches itself to a web form, reads the fields as they are filled in or submitted, and sends a copy to a server the attacker controls. [What is formjacking?](https://www.scriptmonitoring.com/blog/what-is-formjacking/) ### JavaScript injection Getting JavaScript that the site owner did not authorize to run on a page, for example through a compromised third-party library, a hijacked tag manager container or a cross-site scripting flaw. [JavaScript injection](https://www.scriptmonitoring.com/blog/javascript-injection/). To stop a script once you have found it, see [Blocks](https://docs.scriptmonitoring.com/blocks/). ### Shadow code Scripts running on your pages that nobody on your team chose or reviewed, often loaded indirectly by another vendor's script, an old tag or a platform plugin. [Shadow code](https://www.scriptmonitoring.com/blog/shadow-code/) ### Homoglyph attack Using characters that look the same as others, such as a Cyrillic "а" in place of a Latin "a", so that a malicious domain or script URL passes as a trusted one. [Homoglyph attacks](https://www.scriptmonitoring.com/blog/homoglyph-attack/) ### JavaScript obfuscation Rewriting code so that people find it hard to read while it still behaves the same, by renaming identifiers, encoding strings and restructuring the logic. Vendors use it to protect their code, and attackers use it to hide skimmers. [JavaScript obfuscation](https://www.scriptmonitoring.com/blog/javascript-obfuscation/) ## Browser controls ### Content Security Policy An HTTP response header (CSP) that tells the browser which origins a page may load scripts, styles, frames and connections from, and where to send a report when something breaks the policy. It controls where code comes from, not what allowed code does. [Content Security Policy](https://www.scriptmonitoring.com/blog/content-security-policy/). To send reports to Script Monitoring, see [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/). ### Subresource Integrity A browser check (SRI) in which a script or stylesheet tag carries a cryptographic hash in its `integrity` attribute, and the browser refuses to run the file if its contents do not match. It suits files that do not change between releases. [Subresource Integrity](https://www.scriptmonitoring.com/blog/subresource-integrity/) ## Tag governance ### Tag manager security Controlling what a tag manager such as Google Tag Manager can put on your site: who can edit and publish, which containers your pages may load, and which tags those containers add. A container can add scripts without a code deploy, which is why it needs its own controls. [Tag manager security](https://www.scriptmonitoring.com/blog/tag-manager-security/). To limit which containers can load, see [Approved tags](https://docs.scriptmonitoring.com/approved-tags/). ## PCI DSS ### PCI DSS 4.0.1 The current version of the Payment Card Industry Data Security Standard, published by the PCI Security Standards Council in June 2024. It clarifies version 4.0, whose future-dated requirements, including the two for payment-page scripts, became mandatory on 31 March 2025. [PCI DSS 4.0.1 requirements](https://www.scriptmonitoring.com/blog/pci-dss-4-0-1-requirements/) ### Requirements 6.4.3 and 11.6.1 The two PCI DSS requirements for scripts in the consumer's browser on payment pages. 6.4.3 asks that each payment-page script is authorized, has its integrity assured and is listed in an inventory with a written justification. 11.6.1 asks for a mechanism that detects unauthorized changes to those scripts and to the page's security-impacting HTTP headers, and alerts staff, at least weekly. [How to comply with 6.4.3 and 11.6.1](https://www.scriptmonitoring.com/blog/how-to-comply-with-pci-dss-6-4-3-and-11-6-1/). For the evidence in the dashboard, see [PCI DSS 6.4.3 & 11.6.1](https://docs.scriptmonitoring.com/pci-dss/). ### SAQ A The shortest PCI DSS self-assessment questionnaire, for card-not-present merchants that fully outsource card handling to a compliant provider, for example with a redirect or an embedded payment form. Since the January 2025 update it no longer lists 6.4.3 and 11.6.1, but the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its ecommerce systems. [PCI DSS SAQ A](https://www.scriptmonitoring.com/blog/pci-dss-saq-a/) ### Hosted payment page A payment form served by the payment provider, either on the provider's site after a redirect or in an iframe or hosted fields on the merchant's page, so card data is entered into the provider's systems. The merchant's page around it is still the merchant's, and scripts on it can still interfere. [Hosted payment pages and PCI](https://www.scriptmonitoring.com/blog/hosted-payment-page-pci/). To tell Script Monitoring which pages take payments, see [Payment pages](https://docs.scriptmonitoring.com/payment-pages/). ### Payment page script inventory A list of every script that loads and runs on a payment page, with where it comes from, who owns it and why it is needed: the record requirement 6.4.3 asks for. [Payment page script inventory](https://www.scriptmonitoring.com/blog/payment-page-script-inventory/). To build it in the dashboard, see [Prepare PCI DSS evidence](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/). ## Related - [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/) - [Prepare PCI DSS evidence](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/)