Third-party script through a first-party proxy: code your host rules cannot see

What a proxied script is

Some vendors and tag managers offer to serve their code from a path on your own domain, often to get past ad blockers or browsers’ tracking limits. The script is still a third party’s code, and it still runs with full access to the page, but its address now looks like yours.

What squirrel checks

The scan notes when a request that belongs to a catalogued vendor reached the network through a first-party proxy. The rule warns once per page and vendor.

• proxied-script warns with https://example.com/ loads Example Analytics through a first-party proxy, so a content-security policy or blocklist by host does not see it.
• proxied-script passes with No third-party script is served through a first-party proxy. otherwise.

The point is the controls it defeats. A Content-Security-Policy that allows only your own origin cannot tell this script from yours, a host blocklist does not match it, and the inventory in your privacy notice misses it. The rule does not say proxying is wrong: some teams do it on purpose. It says the vendor is there and your host-based controls cannot see it. Only sampled pages are checked.

How to fix it

If you do not need the proxy, load the vendor from its own host and cover it with your policy and your inventory. If you do, list the vendor in your privacy notice and your vendor register, pin or review the version, and treat the proxy path as code you own.

Rule	third-party/proxied-script
Category	Third-party, part of 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.