URL: /cloud/third-party/script-on-sensitive-page

---
title: "Third-party script on a sensitive page: code that can inject into checkout and sign-in"
description: "A vendor that can inject code into the page loads on a sign-in, checkout, wallet or account page."
---

<Note>**Cloud rule.** The `third-party/*` rules run in cloud audits only. They are not part of the local `squirrel audit`, and a cloud audit includes them once the scan is switched on for your organization's plan; an audit without the scan has no Third parties section and none of these rules appear. The scan never charges credits. It reads at most 8 pages per audit, so a finding is about those pages, not the whole site. See [Third-party rules](/cloud/third-party).</Note>

## What it is

Some vendors do more than measure: their script can add or change content on the page. On a sign-in, checkout, wallet or account page, any such script can read what visitors type and alter what they see. Compromised third-party code is the way most card skimmers reach a checkout.

## What squirrel checks

For each sampled sensitive page (a page whose URL path says it is a sign-in, sign-up, checkout, cart, payment, billing, wallet or account page (see [how a sensitive page is decided](/cloud/third-party#how-a-sensitive-page-is-decided))), the rule looks for a catalogued vendor flagged as able to inject code. It leaves out vendors that belong on such a page or have a rule of their own: payment providers, captchas, sign-in and wallet providers, fraud tools, tag managers (see [Tag manager on a sensitive page](/cloud/third-party/tag-manager-on-sensitive-page)) and session replay (see [Session replay on a sensitive page](/cloud/third-party/session-replay-on-sensitive-page)).

- `script-on-sensitive-page` warns once per page and vendor. Message: `https://example.com/login (login page) loads Example Widget, which can inject code into the page`.
- `script-on-sensitive-page` passes with `No code-injecting third-party script loads on a sensitive page.` otherwise.

The catalogue is finite and curated: a vendor that is not in it is not flagged. Sensitivity comes from the URL path only. Only sampled pages are checked. The issue is rated high only when the same audit also found a vendor on a sensitive page that the catalogue rates as a concern (the rating is internal and never shown).

## How to fix it

Take widgets, chat and personalisation scripts off sign-in and checkout pages, or load them only after the visitor has left the sensitive step. For the ones you keep, load a pinned copy with a subresource integrity value and restrict script sources with a Content-Security-Policy.

| | |
|---|---|
| **Rule** | `third-party/script-on-sensitive-page` |
| **Category** | [Third-party](/cloud/third-party), part of [Security](/rules/security) |
| **Scope** | Site (cloud audits only) |
| **Severity** | warning |
| **Weight** | 1/10 |

## Enable / disable

Cloud audits do not read `squirrel.toml`, so these rules cannot be switched off there. They run whenever the audit includes the third-party scan, and report as skipped when the scan could not run.