Both. Privacy defines what data processing is allowed, while application security controls how code behaves in the browser. If either side is missing, the organisation can end up with scripts that are technically embedded but operationally overprivileged, which creates avoidable exposure.
Why third-party script governance sits across privacy and application security
Third-party scripts are not just a privacy issue and not just an application security issue. Privacy defines whether the collection, sharing, and onward use of data is lawful and expected, while application security governs whether browser-delivered code behaves safely, stays within intended boundaries, and can be monitored or constrained. The practical question is not which team owns it exclusively, but whether both control planes are covering the same script surface.
That division matters because a script can be privacy-compliant in intent and still be technically dangerous in execution, or vice versa. A consent banner does not stop a malicious or overly broad script from reading the DOM, exfiltrating form fields, or altering page behaviour. Likewise, a secure code review does not make unlawful collection acceptable if the script processes data beyond what the user or policy permits. OWASP ASVS is useful here because it frames the security side as a control problem, not a marketing or legal one.
The cleanest operating model is to treat third-party script use as a shared governance problem with two separate tests: is the data use permitted, and is the code trustworthy and bounded. That usually means security and privacy teams should review scripts together, but with different acceptance criteria. Security cares about provenance, execution privilege, integrity, and browser impact; privacy cares about purpose limitation, disclosure, minimisation, retention, and onward transfer. Both conditions must be true for the script to be acceptable in production.
What usually fails when only one side reviews the script
The most common failure is assuming that a vendor contract or privacy notice makes the implementation safe. In practice, third-party scripts often arrive through tag managers, ad-tech, analytics, chat widgets, or embedded support tools, and each of those can expand the browser trust boundary. If the script is compromised, updated without notice, or configured too broadly, it can become a high-leverage path into customer data or session context. The risk is amplified when teams treat embedded code as passive content instead of active software.
Another failure is treating privacy approvals as static. Third-party scripts change, vendors add features, and new endpoints appear after initial approval. That is why supply-chain style control matters even for browser code. OWASP Non-Human Identity Top 10 is relevant as a companion reference when a script depends on tokens, API keys, or other identity-bearing material, because overprivileged or long-lived secrets can turn a simple embed into a durable access path.
A practical governance mistake is to focus on whether the script was approved once, rather than whether it still matches the approved purpose and risk posture. If the script collects more data than documented, loads additional subresources, or sends data to new destinations, the original decision is stale. That is especially important for scripts that can observe keystrokes, form fills, or authenticated page content, because those scripts can see far more than the team initially assumed.
How to structure ownership and control in practice
Organisations do best when they assign one accountable owner for the script inventory and one shared decision path for exceptions. Product, web, security, privacy, and legal all have a role, but no single team sees the full picture alone. The inventory should record what the script does, what data it can reach, which pages it runs on, which vendor hosts it, and what change triggers a re-review. Without that minimum metadata, governance becomes reactive and brittle.
Application security should verify whether the script is necessary, isolated, integrity-protected, and constrained by technical controls such as allowlisting, subresource integrity where feasible, and tight tag manager governance. Privacy should verify whether each script is tied to a documented lawful basis, notice, consent state, or other permitted purpose, and whether its data flow remains within the stated boundaries. When either side cannot answer those questions, the script should be treated as unresolved rather than assumed safe.
At a higher level, this is where browser-side governance intersects with vendor risk and data protection. If the organisation relies heavily on third-party scripts for analytics, experimentation, or customer support, it should expect the control burden to rise with scale. More scripts mean more change, more hidden dependencies, and more chances that a permissive script quietly becomes the easiest place to overcollect data or introduce malicious behaviour. The right response is not blanket prohibition, but disciplined minimisation and continuous review.
Risk and Threat Considerations
Third-party scripts expand both the data-processing surface and the browser attack surface, so failures can create privacy harm and direct compromise at the same time. A script with excessive access can collect data beyond the stated purpose, while a compromised or misconfigured script can exfiltrate form input, alter page behaviour, or relay sensitive session information to an untrusted destination.
Failure mechanism: The organisation approves a vendor or tag once, but the script later changes, gains new data access, or is delivered through a trusted channel that is not technically constrained. Attackers and abusive vendors can exploit that trust to observe, copy, or manipulate data inside the browser context.
Impact: The result can be unlawful processing, customer trust loss, credential or session exposure, and broader supply-chain style compromise of web properties. In regulated environments, the same failure can also create reporting, contractual, and supervisory risk because the organisation cannot prove that script behaviour matched the approved purpose.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Third-party scripts behave as active code with browser-side security impact. |
| V8 — Authorization | Scripts should only access data and actions their purpose requires. | |
| V14 — Data Protection | The question centers on whether processing and data use are permitted. | |
| Recommendation — Review embedded scripts as active code and constrain their behavior, provenance, and exposure paths. Limit script capabilities to the minimum browser access required for its function. Map each script's data collection and sharing to an approved purpose and lawful basis. | ||
| GDPR | A.5.x — Data protection principles | Third-party scripts can change what personal data is collected and shared. |
| Recommendation — Document the lawful basis, purpose, and minimisation scope for each script. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Script governance depends on controlled deployment and change visibility. |
| Recommendation — Control script deployment changes and re-approve significant behavior or destination changes. | ||
Practitioner Guidance
What to prioritise: Start with the scripts that can see logged-in pages, forms, payment flows, support tools, or tag-manager-delivered code with broad reach. Those are the highest-value candidates for review because they combine data exposure with execution privilege.
Decision rule: If a script is allowed to process personal or customer data, require both a privacy approval path and a technical security review before release. If either path cannot explain the script’s current behaviour, treat it as unapproved until the gap is closed.
What to verify: Confirm the exact pages, events, data fields, and third-party endpoints the script can access today, not just what was approved initially. The control should be able to show why the script still matches its documented purpose after vendor updates or tag changes.
Practitioner takeaway: Third-party script governance is strongest when privacy defines the allowed processing and application security defines the allowed behaviour, because either control without the other leaves a real gap in browser-side risk management.
Related resources from NHI Mgmt Group
- When should organisations treat third-party cyber ratings as part of vendor risk governance?
- Should organisations treat third-party integrations as part of authorization governance?
- Should organisations treat third-party OAuth apps as part of identity governance?
- Should organisations treat third-party app access as a governance issue or a security issue?