Proteside Glossary
The Proteside and PCI DSS terms used in this documentation, in alphabetical order.
The names in bold are the ones that appear in the dashboard. When a term has its own page, the link is at the end of the definition.
A
Alert: A warning that the SDK or a verifier found something suspicious, such as an injected script, tampered Pix or a changed header. Each alert has a severity, a type and a source, and stays Open until it's resolved. See Alerts.
ASV: Approved Scanning Vendor, the company approved by the PCI SSC to run external vulnerability scans (requirement 11.3.2). Proteside doesn't replace this scan.
Authorization: The recorded decision that a script can run on the payment page. It requires a justification and can be valid for 90, 180 or 365 days, or have no expiry. When you authorize, Proteside pins the hash of the script's content. See Scripts.
Authorization expired: An authorization whose validity has ended. The script goes back to Needs review and requirement 6.4.3 starts asking for action.
B
Baseline: The first observed value of a security header. It serves as the reference until you authorize another value in PCI DSS Evidence → Headers. See PCI DSS Evidence.
Blocking: The decision to prevent a script from running. Blocking an external script creates a rule that blocks its entire domain, including subdomains. Blocking only works for scripts inserted by JavaScript: a tag written directly in the page HTML keeps loading until it's removed at the source.
Bootstrapper: The first part of the snippet, pasted directly into the HTML. It runs before any other script and applies the blocking rules before scripts get into the page. See Integration.
C
CSP: Content Security Policy, the HTTP header that tells the browser where the page can load scripts and other resources from. It's one of the headers Proteside tracks. See Content Security Policy and headers.
D
Developer mode: Pauses the SDK on the store: it stops protecting, and SDK Health shows the SDK as paused. Use it only during testing and remember to turn it off.
E
Evidence: The record that shows the assessor that a PCI DSS control works: inventory, authorizations with justifications, alerts, verifications and reports. Proteside generates supporting evidence for requirements 6.4.3 and 11.6.1; it isn't a certification. See PCI DSS Evidence.
Expected iframe origin: A domain that can display an iframe in the checkout, usually your PSP's. An iframe from another origin triggers an alert.
F
First-party script: An inline script, or a script served from the store's domain or one of its subdomains.
G
GTM container: A Google Tag Manager container, identified by GTM-…. In Payment protection you can list the
allowed containers; all others are blocked.
H
Hash: A fingerprint of content, calculated with SHA-256. Any change to the content produces a different hash. Proteside uses hashes to compare scripts and headers with the authorized version and to prove that a report hasn't been altered.
I
Integrity: The assurance that a script is still the same as what was authorized. The statuses are Intact (same), Mismatch (changed), Pending (no hash yet) and Monitored (the content can't be read, so the SDK tracks its behavior). See Scripts.
Inventory: The list of every script the SDK has seen on the store's pages, with type, status and history. It's the basis of requirement 6.4.3.
M
Magecart: The name given to the groups and techniques behind skimming on online stores. See Skimming.
Mismatch: The integrity status of a script whose current content doesn't match the authorized hash. It triggers an alert and sends the script back for review.
O
Organization: Your Proteside account. It holds the plan, billing and stores. The person who created the organization is the only one who can subscribe or change plans.
P
Payment integrity: The check that the payment data displayed in the checkout, such as the Pix key, the QR code and the boleto, belongs to your store. See Payment integrity.
Payment page: Any page where the customer sees or enters payment data, such as the checkout, a cart with payment and the Pix page. The snippet must be on all of them for full coverage.
PCI DSS: The payment card industry's data security standard. Version 4.0 added requirements 6.4.3 and 11.6.1, covering scripts and change detection on payment pages.
Policy: A criterion that decides on scripts automatically, such as "authorize the files from the site's build" or "block known threats". It can act on its own (Automatic) or only suggest the decision (Recommend). See Approval policies.
Protection mode: How the SDK reacts to a threat. In Monitor, it detects and alerts. In Block, it also tries to undo the tampering, for example by restoring the original Pix key. Blocking rules apply in both modes. See Configuration.
PSP: Payment service provider, such as a gateway or sub-acquirer, that processes the payment in the checkout.
Q
QSA: Qualified Security Assessor, the auditor qualified by the PCI SSC who assesses the store's compliance. This is who you hand the evidence reports to.
R
Release channel: The SDK version the store uses: stable (default, validated versions) or latest (every release). The channel is
set by the SDK address in the snippet. See Stable and latest channels.
Report: An immutable snapshot of the evidence for a period, in PDF, JSON and CSV, with a SHA-256 for verification. Generated every week or on demand.
Re-review: The state of a script that already had a decision and went back to Needs review because its content changed. It shows up in the Re-review tab in Scripts.
Role: A person's access level in a store. Owner and Admin can change data; Member and Viewer can only view. See Team.
Rule: A direct order to the SDK to Block or Allow scripts from a domain or a URL. An allow rule overrides block rules. See Rules.
S
Script: A JavaScript file or snippet of code that runs on the page. It can be external, loaded from an address, or inline, written directly in the HTML.
SDK: The Proteside code that runs in the customer's browser and watches the payment page. See Integration.
SDK key: The store's public identifier, in the format pk_live_3f9c…. It goes inside the snippet and is in
Settings → Pages & Domains. It isn't a secret, but it identifies your store.
Security header: An HTTP header sent by the server that strengthens the page's security, such as Content-Security-Policy and
Strict-Transport-Security. Requirement 11.6.1 calls for detecting changes to these headers.
Severity: How serious an alert is: Critical, High, Medium, Low or Info.
Skimming: The theft of card data by a malicious script inserted into the payment page, which copies what the customer types and sends it to the attacker. It's the main attack that requirements 6.4.3 and 11.6.1 address.
Snippet: The piece of code you paste into the <head> of your payment pages to load the SDK. It's in
Settings → Pages & Domains. See Installing the snippet.
Snooze: Hide an open alert for 1, 7 or 30 days without resolving it. The alert stays open and shows up again after that period.
SRI: Subresource Integrity, the integrity attribute of a <script> tag that makes the browser reject the file if its
content changes. Proteside suggests the attribute value in a script's details.
Synthetic check: An automated visit Proteside makes to the monitored pages, in a browser with no person behind it, to generate evidence even without customer traffic.
T
Third-party script: A script served by a known vendor in Proteside's catalog, such as a PSP or an analytics tool.
Trusted recipient: A Pix key, cryptocurrency address, UPI VPA or boleto bank that belongs to your store. The SDK compares the recipient displayed in the checkout with this list and alerts on the first mismatch. Proteside stores only the key's hash. See Payment protection.
U
Unknown script: A third-party script whose domain isn't in Proteside's vendor catalog. It deserves extra attention during review.
V
Verifier: The process that, every 6 hours, re-downloads the store's external scripts on the server and compares their hash with the authorized one.