How should security teams prevent formjacking on websites with third-party scripts and forms?

Why This Matters for Security Teams

Formjacking is not just a website code issue; it is an identity and supply chain issue. When third-party scripts, payment widgets, chat tools, or analytics tags can read form fields, the browser becomes part of the trust boundary. That makes static allowlists, legacy plugin trust models, and broad script permissions especially risky. The OWASP Non-Human Identity Top 10 is relevant here because injected or abused scripts often behave like unmanaged machine actors with access to sensitive user data.

NHIMG research shows how often third-party exposure becomes the real problem: in The State of Non-Human Identity Security, 85% of organisations reported lacking full visibility into third-party vendors connected via OAuth apps. That same visibility gap shows up on websites when teams cannot confidently enumerate every script that can touch a form. In practice, many security teams discover formjacking only after card data or credentials have already been harvested, rather than through intentional monitoring of browser-side trust changes.

How It Works in Practice

The effective defence is to treat the page as a controlled execution environment. Start by reducing script reach with a strict Content Security Policy, then require HTTPS everywhere so injected code cannot be modified in transit. Review every third-party script and form dependency, including tags added by marketing or support teams, because the risk often enters through non-technical change paths. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports this approach through access control, monitoring, and configuration management expectations.

Operationally, teams should separate high-risk forms from generic page scripts, pin approved assets where possible, and monitor for unexpected DOM changes, outbound requests, or new script origins. Use a WAF to block known malicious patterns, but do not rely on it alone because client-side theft happens before server-side inspection in many cases. Pair logging with periodic browser-side testing so security can detect whether a payment or login form is reading from unapproved sources. NHIMG guidance on The 52 NHI Breaches Report and Reviewdog GitHub Action supply chain attack shows the same pattern across environments: compromised code paths frequently become the fastest route to data exposure.

These controls tend to break down when business teams can add scripts directly to production pages without security review, because browser trust becomes fragmented across too many owners.

Common Variations and Edge Cases

Tighter script control often increases rollout overhead, requiring organisations to balance fraud reduction against marketing, analytics, and support functionality. There is no universal standard for this yet, but current guidance suggests using different policies for public pages, checkout flows, and authenticated account portals rather than applying one blanket rule everywhere.

Some environments also rely on iframe embeds, tag managers, or server-side form handlers that complicate monitoring. In those cases, security teams should narrow where user input is collected, reduce the number of parties that can execute in the browser, and treat every new vendor tag as a change to the threat model. The Ultimate Guide to NHIs is useful here because third-party exposure and over-privileged access are recurring drivers of compromise, even when the initial issue looks like a web scripting problem.

For high-risk checkout flows, best practice is evolving toward stronger client-side integrity checks, tighter segregation of payment logic, and continuous review of any code that can access form values. Teams should assume that once a script can read the DOM, it can exfiltrate more than intended unless constrained by policy and design. This guidance becomes less reliable in heavily customised CMS deployments where plugins inject code dynamically after page load, because security ownership is often unclear and controls drift quickly.

Related resources from NHI Mgmt Group

• How should security teams govern third-party scripts that can affect transactions or login flows?
• How should security teams control third-party scripts on payment pages?
• How should security teams govern third-party browser scripts that can see user input?
• How should security teams govern third-party AI agents that use OAuth access?