# Frontend security: review every script that can change what a user sees Canonical: https://www.web3sec.news/blog/frontend-third-party-script-security Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Frontend & third-party code Published: 2026-11-08 Updated: 2026-11-08 A practical review of browser code, tag managers and content security policies, including the interactions a successful build can still break. ### Diagram: Content is evidence. Approval is authority. Keep source material separate from the authority to act. ![Sources enter a working context and produce a proposal. A separate approval gate checks scope before a tool action. Untrusted content cannot authorize execution.](https://www.web3sec.news/diagrams/trust-boundary.svg) [Full-size SVG](https://www.web3sec.news/diagrams/trust-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/trust-boundary.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Give the browser dependency list an owner Assign a frontend engineer to maintain a record of scripts that execute on important pages. Begin with a fresh browser profile and inspect the network log during login, account recovery, checkout and administrative actions. Include scripts introduced through tag managers, support widgets and feature experiments. A package manifest alone will miss code loaded by a remote snippet. Record why each integration exists, who can publish changes to it and the fields visible to that code. The practical review question is whether the application needs the integration on that page. A support widget that is useful on a documentation page may add little value to a sensitive account screen. Ask the product owner to identify the behavior that would stop working if it were removed. Delete integrations without a current owner or purpose, and make exceptions specific to an integration and route rather than approving an entire vendor category. ## Separate useful controls from assumptions OWASP describes why third-party JavaScript belongs inside the browser trust discussion: it can change the page and observe information available there. A convention that asks a vendor to read only an approved analytics object is not a browser-enforced sandbox. For each remaining dependency, document what actually limits its access. A separate-origin, appropriately sandboxed frame and a script running inside the host document are different arrangements; neither should be described using a vague label such as isolated. For immutable external assets, evaluate whether Subresource Integrity and the vendor’s cross-origin configuration support a reviewed, fixed version. Keep the update owner and rollback artifact alongside the integrity value. For mutable tag containers, review publishing permissions and release history as production change controls. Self-hosting a script changes where it is fetched; it does not make the script trustworthy or remove the need to review future updates. ## Test the policy against the delivered application Use the delivered HTML and response headers as the test inputs. MDN explains the distinction between allowed script locations and nonce- or hash-based authorization of inline scripts. Choose the policy architecture deliberately. A source allowlist is not a claim that every file on an allowed origin is safe. If nonces are part of the design, the value and the header must be generated and applied consistently for each response; a constant value copied into a template does not provide that property. Then exercise the application in a browser with the policy enforced. During Web3Sec’s rebuild, the build succeeded and the pages looked correct, but an inline framework bootstrap was blocked and filters stayed inactive. We changed the supported build configuration and retested the actual interactions. That example is a release lesson, not a universal recommendation about a bundler: the artifact the browser receives determines what the policy must authorize. ## Practice removal and a failed release In a staging environment, block one optional integration and repeat the important user journeys. The exercise fails if a nonessential analytics or support dependency prevents a user from completing a core task. Record whether the UI explains a failure, whether an alternate path exists and whether any monitoring detects the interruption. Review the application with reduced motion and without JavaScript as separate usability checks; an animation should not hide essential content indefinitely. Prepare a release record containing the source revision, browser policy, integration inventory and tested journeys. Keep a known-good artifact and the authority needed to restore it. If a vendor is suspected to be compromised, the responder needs a way to remove its code without using that vendor’s interface. After containment, preserve the relevant page artifacts and publishing history before deciding whether users or sessions require further investigation. ## Controls to take away - A remote script can change without a change to your repository. - A successful build does not prove that browser policy and hydration agree. - Make removal of optional code a procedure the team can execute. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Record browser-loaded scripts on sensitive user journeys. - [ ] Name an owner and publishing authority for each integration. - [ ] Remove a dependency without a present, specific purpose. - [ ] Verify policy headers on the delivered response. - [ ] Test real interactions with the policy enforced. - [ ] Block an optional vendor in staging and verify core workflows still work. ## Sources & further reading - [OWASP: third-party JavaScript management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) - [MDN: script-src policy behavior, hashes and nonces](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)