iframe的sandbox属性限制规则及安全配置答疑

关于sandbox的默认限制与allow-scripts规则 #

给iframe加上sandbox属性且不配置任何允许值时，浏览器会对内部内容施加全套沙箱限制，核心限制包括：

• 所有脚本完全无法执行：不管是内联JS、外部引入的JS文件、DOM元素的内联事件（比如onclick）、javascript:开头的伪链接，全都会被直接拦截
• 强制异源隔离：沙箱内的内容会被判定为独立的不可信源，完全无法访问父页面的DOM、cookie、localStorage等任何数据，也不能携带父页面的身份凭证发请求
• 禁用所有可能改变父页面状态的能力：不能提交表单、不能通过修改URL跳转父页面、不能调用window.open弹新窗口、不能触发alert/confirm/prompt这类原生弹窗
• 禁用所有高权限API：不能调用摄像头、麦克风、地理位置等授权接口，不能申请全屏、指针锁定，不能加载插件，音视频自动播放、表单自动填充这类自动触发的特性也会被禁用

关于allow-scripts的问题，结论非常明确：

1. 如果你要让iframe里的JavaScript正常运行，必须配置allow-scripts，没有这个值的话所有脚本都没有运行权限，不存在绕过可能。
2. 只加allow-scripts绝对不代表可以安全运行不可信JavaScript。首先要记住一个铁则：绝对不要同时配置allow-same-origin和allow-scripts，两个值同时开的话，沙箱里的脚本可以直接移除iframe的sandbox属性，直接拿到和父页面同等的权限，沙箱直接作废。就算只开allow-scripts不开allow-same-origin，不可信JS依然可以跑挖矿脚本、写无限循环卡用户浏览器、做钓鱼界面诱导用户输入信息、发大量垃圾请求消耗带宽，这些风险单靠sandbox是拦不住的。如果后续要支持JS运行，除了正确配置sandbox，最好把用户代码托管在和主站完全隔离的独立域名下，再搭配CSP规则做多层防护。

仅支持HTML+CSS场景下的配置有效性 #

如果你现阶段只需要运行用户提交的HTML+CSS代码，直接配置不带任何允许值的sandbox属性，完全可以阻断所有脚本执行，满足基础安全要求。
有几个容易踩的坑注意避开就不会出问题：

• 不要随便给sandbox加额外的允许值，尤其是allow-scripts、allow-top-navigation这类高风险权限，保持空sandbox默认全关的状态最稳妥
• 可以给iframe返回的内容额外加CSP响应头，配置script-src 'none'，就算遇到极端的浏览器兼容问题导致sandbox失效，CSP也能兜底拦住脚本
• 如果你用srcdoc属性往iframe里注入用户代码，一定要对用户输入的内容做HTML转义，避免恶意代码逃出iframe直接在父页面执行

内容的提问来源于stack exchange，提问作者Jacob Hornbeck