The browser checks each script against a policy before deciding whether to run it. As long as the policy only allows trustworthy scripts and disallows dynamic code loading, the browser will not run programs from untrusted authors regardless of the HTML document's structure. This shifts the security burden to policy authors. Studies<ref></ref> have cast doubt on the efficacy of host whitelist based policies.In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.Modern<ref></ref> CSP policies allow using nonces<ref></ref> to mark scripts in the HTML document as safe to run instead of keeping the policy entirely separate from the page content. As long as trusted nonces only appear on trustworthy scripts, the browser will not run programs from untrusted authors. Some large application providers report having successfully deployed nonce-based policies.<ref></ref><ref></ref>  The popularity of client-side frameworks has changed how attackers craft XSS.<ref></ref>Script gadgets are legitimate JavaScript fragments within an application’s legitimate code base … We demonstrate that these gadgets are omnipresent in almost all modern JavaScript frameworks and present an empirical study showing the prevalence of script gadgets in productive code. As a result, we assume most mitigation techniques in web applications written today can be bypassed.Trusted types<ref></ref> changes Web APIs to check that values have been trademarked as trusted. As long as programs only trademark trustworthy values, an attacker who controls a JavaScript string value cannot cause XSS. Trusted types are designed to be auditable by blue teams. Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.<ref>L. Shar and H. B. K. Tan, "Automated removal of cross site scripting vulnerabilities in web applications," "Information and Software Technology," vol. 54, "(5)," pp. 467-478, 2012.</ref>  When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-"safe" cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics).<ref></ref> The feature is implemented in Google Chrome since version 63 and Firefox since version 60.<ref></ref>  This cross-site scripting (XSS) cheat sheet contains many vectors that can help you bypass WAFs and filters.