如何禁用动态添加的<script>标签，实现用户生成内容的安全XSS防护

关于禁用动态插入script执行的方案 #

原生浏览器没有提供全局开关直接拦截所有初始解析完成后插入的<script>标签执行，但你的场景可以通过配置内容安全策略(CSP) 实现完全等价的效果：
你可以在响应头或者页面meta标签配置CSP的script-src指令，仅允许你的业务域名、信任的静态资源CDN、以及打包工具生成的JS哈希值/随机nonce值加载，同时禁用所有内联脚本。配置完成后，所有不在白名单内的动态插入脚本都会被浏览器直接拦截执行，全程是浏览器原生能力实现，没有额外的业务侧性能开销，也不需要限制用户输入<、>这类字符，不会影响用户体验。
结合你提到的所有JS懒加载都是通过固定路径的import("/some/js/module")实现、打包工具会重定向路径的场景，CSP规则配置成本极低，完全可以覆盖你的业务需求。

关于iframe沙箱渲染用户生成内容的方案 #

这是行业内已经大规模落地的成熟方案，通过iframe的sandbox属性可以实现完全的运行环境隔离：

• 只要给iframe加上sandbox属性且不配置allow-same-origin权限，即便iframe内容和父页面同域名，浏览器也会强制将iframe放在独立的安全上下文中，内部运行的JS完全无法访问父页面的DOM、Cookie、存储等任何资源，也无法操控父页面跳转、弹出窗口等行为。
• 如果你允许用户插入脚本实现自定义交互组件，只需给sandbox额外加allow-scripts权限即可，脚本仅能在iframe隔离环境内运行，不会影响外层父页面。如果你不需要用户脚本执行能力，不配置allow-scripts即可，此时iframe内所有<script>标签、onclick等事件监听都会被浏览器直接禁用，防护强度远高于常规的内容消毒。
• 父页面可以直接通过iframe.contentDocumentAPI向iframe内写入用户生成的Markdown/HTML内容，不需要额外的静态资源服务配合，落地成本很低。

两种方案可以组合使用：外层主页面配置严格CSP拦截非法脚本，用户生成内容统一放到带sandbox属性的iframe内渲染，完全可以替换你当前的强限制规则，同时解决体验差、性能开销高的问题。

内容的提问来源于stack exchange，提问作者Sam Claus