Events and detections
The event types the SDK sends, what each one detects, its severity and when it becomes an alert in the dashboard.
The SDK sends the dashboard two kinds of events: detections (something suspicious happened on the page) and telemetry (pageviews, inventory, payment validations). Detections become alerts; telemetry feeds the Scripts inventory, SDK Health and Payment Integrity.
How an event becomes an alert
- The dashboard sets the severity, not the SDK. The severity reported by the SDK is recorded on the alert as "Severity reported by the SDK". The tables below show the base severity in the dashboard.
- Repeated events don't create new alerts. While there's an open alert for the same problem (for example, the same script or the same exfiltration destination), new occurrences are added to the existing alert. If the alert was already resolved, a new occurrence opens a new alert.
- The notification goes out only when the alert is created. Repeated occurrences don't notify again.
- Scripts that were already in the HTML when the SDK started don't raise a block alert: they show up in Scripts with a note that they keep loading from the HTML.
See how to handle alerts in Alerts.
Calibration
During the first 30 seconds of each page load (adjustable from 10 to 120 s), the SDK learns what's normal on the
page. During calibration, these detections stay silent, and whatever shows up becomes part of the page's baseline:
SCRIPT_INJECTION, KEYLOGGER_DETECTED, EXFILTRATION_ATTEMPT, WEBSOCKET_EXFILTRATION, FORM_ACTION_HIJACK,
OVERLAY_DETECTED and tampering with the text or image of payment codes.
All other detections work from the start, including rule-based blocks, recipient verification, the clipboard and iframes.
Scripts
| Event | What it detects | Severity | Alert |
|---|---|---|---|
SCRIPT_INJECTION | A new executable script appears after calibration, outside what the page already had. Framework files from the page's own origin (/_next/static/, /_nuxt/ and similar) are ignored. | high, adjusted | yes |
SCRIPT_MODIFIED | A known script reappears with different content. Only when the content can be read (inline script, or external script with CORS enabled). | high, adjusted | yes |
SCRIPT_BLOCKED | A script matched a blocking rule and was stopped. | high | yes, unless the script was already in the HTML |
GTM_CONTAINER_BLOCKED | A Google Tag Manager container or a gtag.js tag outside the Allowed GTM containers list. | high | yes |
Adjusted severity: for SCRIPT_INJECTION and SCRIPT_MODIFIED, the dashboard raises it to critical when the
vendor is flagged as a threat in the catalog, lowers it to low when it's a cataloged vendor, and uses medium
for first-party scripts and inline scripts. In all other cases, it stays high.
Customer data
| Event | What it detects | Severity | Alert |
|---|---|---|---|
KEYLOGGER_DETECTED | A script starts listening to keydown, keyup, input, change or paste on a sensitive field after calibration. One event per listener registration. | critical | yes |
EXFILTRATION_ATTEMPT | A request (fetch, XHR, beacon or image) to an untrusted host carries a card number (Luhn-validated), CPF, CNPJ, email address or Pix key. Images with a long query string sent to an untrusted host are reported even without these patterns. | adjusted | yes |
WEBSOCKET_EXFILTRATION | A WebSocket connection to an unknown host after calibration. Messages aren't inspected. | critical | yes |
FIELD_ACCESS | A script registered a listener on a sensitive field. One event per script, field type and listener type. | info | no |
Trusted hosts for exfiltration are: the page's own origin, the Proteside API, known payment providers and analytics tools, and the hosts the page used during calibration. The SDK inspects up to 64 KB of each body and sends only the names of the patterns it found, never the content.
Adjusted severity: exfiltration is critical when the destination is a vendor flagged as a threat or when the body contains a card number, CPF or CNPJ; it's low when the destination is a payment processor or a cataloged vendor; in all other cases, it's high.
Forms, iframes and overlays
| Event | What it detects | Severity | Alert |
|---|---|---|---|
FORM_ACTION_HIJACK | A form's action attribute changed, including on forms created later. | critical | yes |
OVERLAY_DETECTED | A positioned element (absolute or fixed, z-index above 100) covers the center of a sensitive field or the payment area. Elements with modal, cookie, consent, gdpr, banner, toast, notification or tooltip in their class or id are ignored. Repeats on every check for as long as it persists. | high | yes |
IFRAME_REPLACED | The address of a known payment provider's iframe changed. | high | yes |
IFRAME_UNEXPECTED | A payment provider iframe outside the Expected iframe origins, or any iframe covering half or more of an expected iframe. Requires the list to be filled in. | high | yes |
CARD_FIELD_OUTSIDE_VAULT | A card field you can type into on the main page, outside the provider's iframe. Requires the origin list to be filled in. | high | yes |
Payment
| Event | What it detects | Severity | Alert |
|---|---|---|---|
PIX_TAMPERED | The displayed Pix code changed to one that doesn't match the reference, or the recipient isn't among the trusted ones. | critical | yes |
BOLETO_TAMPERED | The digit line changed, or the bank isn't among the trusted ones. | critical | yes |
CRYPTO_ADDRESS_SWAP | The Bitcoin or Ethereum address changed, or isn't among the trusted ones. | critical | yes |
UPI_TAMPERED | The UPI code changed, or the VPA isn't among the trusted ones. | critical | yes |
QR_TAMPERED | The code for another QR-based method (PayNow, PromptPay, DuitNow, QR Ph, HK FPS, Transferencias 3.0, CoDi or QR wallet) changed, or a QR code image started coming from a different domain. | critical | yes |
AMOUNT_TAMPERED | The code's amount differs from the one passed to expectPayment(), or the same recipient appeared with a different amount. | critical | yes |
CLIPBOARD_HIJACK | The content copied to the clipboard looks like a payment code and doesn't match the reference. | high | yes |
PAYMENT_VALIDATED | A payment code was read and validated. Feeds Payment Integrity. | info | no |
Details in Payment integrity and Pix.
Environment and installation
| Event | What it detects | Severity | Alert |
|---|---|---|---|
SERVICE_WORKER_BLOCKED | A registered service worker (new or existing) outside the Allowed service workers. Requires the list to be filled in. | high | yes |
SERVICE_WORKER_REGISTERED | An allowed service worker was registered. | info | no |
INSTALLATION_ORDER_WARNING | There are scripts before the bootstrapper in the <head>. Not sent if Installation order is set to Silent. | medium | yes |
Telemetry
These events never become alerts:
| Event | When it's sent |
|---|---|
PAGEVIEW | On every page load and every Proteside.pageChanged(). When the SDK is paused, it's the only event sent. |
BASELINE_CALIBRATING | When calibration starts. |
BASELINE_CLASSIFIED | Right after, with the page's script inventory (address, content hash, size and classification). |
BASELINE_ESTABLISHED | When calibration ends, with the totals it learned. |
Generated by the dashboard
Some alerts don't come from an SDK event, but from server-side checks:
| Alert | Source | Severity |
|---|---|---|
SCRIPT_INTEGRITY_MISMATCH | An authorized script's content changed compared to the approved hash. | high |
HEADER_CHANGED | A security header on the payment page changed value. | medium |
CSP_VIOLATION | A CSP report sent to Proteside points to a host outside the inventory. See CSP and headers. | low |
SDK_SILENT | A domain with history went 24 hours without real sessions. It resolves itself when traffic comes back. | medium |