Third-Party Script Governance

A third-party script — analytics, advertising, chat, session recording, tag management — executes with the page's full privileges. It can read the DOM, read anything the page holds, and issue authenticated requests.

Each is added individually because a business team asked, each is individually justified, and the aggregate is a page whose security posture is determined by the least careful vendor on it.

Why it matters

It is one of the few places where the security boundary is entirely outside the organisation's control, and it is typically governed less carefully than a code dependency — because the page is treated as marketing surface rather than as an execution environment.

It is also frequently the majority of the JavaScript payload, which makes it a performance decision at the same time, and one nobody owns.

Implementation patterns

• A review with a named approver for anything added to the page. Usually absent, and it is the control that addresses the underlying dynamic.
• A content security policy, which is the most effective single mitigation and which requires the application to be built without inline scripts and arbitrary sources.
• Subresource integrity on anything loaded from a third party, so a compromised or substituted file does not execute.
• Tokens stored so a script cannot read them. Local storage is readable by any injected script; an HTTP-only cookie is not — and the choice is architectural, because it determines what a cross-site scripting flaw can do.
• Budget the third-party share separately in the performance budget, since it is the part that grows and the part nobody sees in the build.
• Periodic review of what is still needed, since scripts accumulate and are removed never — the same dynamic as feature flags, unused indexes and unread models.

Industry example

Financial applications such as Groww and CRED have the sharpest version of the problem: the page holds session material and displays account data, so a compromised vendor script is a route to both. The mitigation that matters most is not detection but reducing what is on the page at all, and the review gate is what makes that a decision rather than an accretion.

Failure scenarios

• Scripts added without review, each justified and collectively unbounded.
• No content security policy, leaving injection unconstrained.
• Tokens in local storage, so an injection becomes a session compromise.
• No integrity checks, so a compromised vendor CDN executes arbitrary code.
• Never reviewing what is still needed, so the payload and the attack surface both grow monotonically.

Trade-offs

A review gate slows down marketing and analytics work, and a strict content security policy breaks scripts that were working — which produces pressure to loosen it.

The resolution is a fast, staffed review rather than a strict one, since a slow gate is bypassed and a bypassed gate provides nothing. And loosening a policy for one vendor should be a recorded exception with a review date, not a permanent widening — because the widening is what the next vendor's script will use.

Interview question

"Count the third-party scripts on your production page. For each one, tell me who approved it, what it can access, and what would happen if that vendor were compromised tonight."