我有一个请求使用嵌入在页面中的一次性 token 来确保 CSRF 保护 - 攻击者可能会欺骗我的用户发出非法请求，但他们无法获得 token ，即使他们它可以随着每个请求而改变并且可以过期吗？
到目前为止，非常安全。
我想用服务 worker 实现后台同步，这样用户就可以离线发布数据，然后在获得连接后发送该数据。
但是，这意味着该页面不可用于获取 CSRF token ，并且在用户构建它时与请求链接的任何 token 在数据实际发送时可能无效。
这似乎是任何渐进式网站的普遍问题，处理它的最佳做法是什么？
我认为 background-sync 可以请求一个新的 token ，将它应用到要发送的数据然后发送它，这仍然是一个 CSRF 攻击者无法利用的循环，但我不是肯定的。任何人都可以确认这一点吗？
我是否缺少 Service Worker 或后台同步的某些功能？
最佳答案
我没有资格为 CSRF 主题的“最佳实践”发言，但根据我对 OWASP guidelines on CSRF 的理解你的想法是正确的。
目前，我以类似的方式使用 OAuth:向各个客户端发出刷新和不记名 token 。刷新 token 的生命周期明显长于不记名 token 。客户端可以选择使用刷新 token 来创建他们认为合适的新承载 token 。一些客户端可能会选择“完全轮换”，即在每个请求上都有一个新的承载。有些人可能会选择使用一个承载，直到它报告失败，然后再创建一个新承载。
在您的场景中，您的后台同步将请求并接收刷新 token 和不记名 token 。它可以继续使用手头的不记名 token 构建 URL，然后在尝试失败时进行同步时，使用刷新 token 生成新的不记名并使用新的不记名重建 URL。当然，如果刷新已经过期(或被撤销)，那么你离线时间太长，你需要重新授权。
关于service-worker - Service Worker 后台同步与 CSRF 保护的最佳实践模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38795709/