Google Apps Script表格插件XSS防御方案有效性及优化问询

当前防御是否足够？ #

不够。你现有的服务端字符过滤和有限通信方式只能覆盖部分风险，仍存在多个安全漏洞和场景盲区。

优化方向 #

• 精准调整sanitize规则：
  仅允许字母数字++///=的规则要么会误杀合法业务输入（如果需要支持其他字符），要么未对输入的格式、业务合理性做验证（比如即使字符合法，也可能是恶意构造的内容）。建议根据实际业务需求定义允许的字符集，同时添加格式校验（比如Base64内容要符合Base64结构），对输入的长度、类型做严格限制。
• 限制google.script.run的滥用：
  攻击者能通过调试器调用该API，但你可以在服务端函数里加上下文校验：
  • 用Session.getActiveUser()验证调用者是否为当前文档的授权用户，或具备对应操作权限；
  • 敏感函数（比如修改DocumentProperties的函数）仅对文档所有者/特定权限用户开放；
  • 隐藏不必要的服务端函数，只暴露业务必需的接口，避免攻击者调用未公开的敏感逻辑。
• 加固DocumentProperties的安全：
  • 不要存储敏感数据，它属于文档级存储，所有有编辑权限的用户都能访问；
  • 对存储的数据进行加密，即使被非法获取也无法直接读取明文；
  • 写入前验证数据结构，确保只有符合业务预期的格式被存储，拒绝恶意构造的数据。
• 补充客户端验证：
  服务端验证是核心，但客户端可以做前置校验，提前拦截明显的恶意输入，减少服务端负载。
• 配置GAS安全选项：
  在脚本项目设置中开启授权对话框，确保脚本运行在合法授权上下文；部署时避免选择「任何人（含匿名）可访问」，严格限制脚本的访问范围。

需防范的XSS攻击类型 #

• 客户端反射型XSS：
  如果插件有用户输入直接在侧边栏/对话框展示的场景，未过滤的输入（比如<script>alert(1)</script>）会被执行。要对输出到HTML的内容做转义，把特殊字符（</>/"/'）转换成HTML实体。
• 存储型XSS：
  恶意数据被存入DocumentProperties后，后续读取并渲染到客户端时触发XSS。所以输入过滤+输出转义都要做，不能只依赖其中一环。
• google.script.run滥用引发的间接XSS：
  攻击者通过调试器调用服务端函数修改DocumentProperties，注入恶意内容，之后客户端渲染时触发XSS。这正是你遇到的场景，需要通过权限校验和函数访问控制来阻断。
• DOM型XSS：
  客户端JS直接用URL参数、DocumentProperties数据操作DOM（比如innerHTML、document.write），未做转义导致脚本执行。优先使用textContent替代危险的DOM操作方法，必须用innerHTML时要先转义内容。

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