CSRF 利用的 cookies 验证进行未授权访问，不用 cookies 作为验证就没问题（大概）

API 一般都有私钥的，所以不需要 CSRF 那个了

#2 楼 @huacnlee 现在是怕 app 接口被抓取，然后胡乱调用，想防止下，密钥加到请求头里吗？这样被抓取的话，感觉意义不大了

#1 楼 @Rei 主要是想防止这个接口被非 APP 调用

#4 楼 @ghn645568344 SSL 抓不到

#3 楼 @ghn645568344 给个攻击例子？不明白被抓取是什么意思。

#1 楼 @Rei 表示我之前都是通过当前登陆用户做接口请求验证的，不用 cookies 验证用什么做验证呢？求指点

app 用 token 认证身份就够了。也就是实现一个完整的或者简化的 oauth2 认证。

#7 楼 @xiaobai2 access_token 放参数或者头部

#3 楼 @ghn645568344 给接口加上时间戳，设置有效时间窗口，并且在提交参数的时候根据密钥计算签名，服务端验证。当然 app 端记得把密钥存好，做好代码混淆，这样差不多就抓不到了。

#5 楼 @huacnlee 手机上自己做个中间人就能抓到了吧。

从 Header 中读取 authentication token，应该就不需要其他单独的 csrf token 了

#4 楼 @ghn645568344 你没有任何方法完美防止接口被非 API 调用。

不如想一下，即使被非 API 调用，如何避免这些调用对你 API 产生实际影响。

CSRF 对 API 没有用。token 对 API 也是作为验证，非 API 调用可以模拟 token 的机制，照样调用你，所以对防止恶意请求没有作用。

说明楼主根本不理解什么叫「跨域」

对接口调用次数进行限制，例如一分钟内只能调用多少次

#14 楼 @hooopo 正是如此，我觉得大家的讨论一开始就偏离了，CSRF 是“跨站请求伪造”，API（尤其是楼主所说的 APP）根本就不存在“跨站”的问题。所以回答应该是：不是接口需要不需要 CSRF 防护，而是接口完全不能做、没办法做 CSRF 防护。然后才应该是讨论怎么保证 API 的安全性，比如 https 防监听、token 认证之类的。

帮大家复习下：CSRF 是一种依赖 web 浏览器的、被混淆过的代理人攻击（deputy attack）。

请注意加粗字体。

总的来说，这是楼主一个对 CSRF 完全缺乏了解，只是囫囵吞枣知道这是一个安全防范措施的初学者提出的一个伪问题，所以务必首先要纠正这个问题本身。也就是说，这个问题是一个病态的问题，错误的问题，我觉得有必要澄清这一点，防止以讹传讹

#16 楼 @sefier 技术讨论干嘛搞得像批斗会一样，最后一段话对解决问题没有帮助，提问者不就是因为不懂所以提问。如果你知道问题所在，可以提供参考资料。

现在前后端分离这么流行，也许楼主说的 APP 就是网页前端，放在同一域名，通过 cookie 验证，这样就需要防 csrf。

我们是这样搞的：

1、APP和服务器接口先约定好一个密钥；
2、登录之后服务器接口返回一个Token；
3、APP在之后需要验证的请求中都要加上这个Token，以及进行签名。

签名方式其实跟很多支付接口一样，把所有的参数加上约定好的密钥进行Sha1或者MD5加密，得到签名字符串，传到服务器接口后再进行验证。

安全问题：
我们会在参数里边加一个timestamp字段，获取当前的时间戳，类似：1485159939.454，一并放进参数列表并签名。
服务器接口会检测时间戳不能误差超出2分钟，然后会在REDIS里边记录这个时间戳（2分钟后自动删除），用来判断重复请求。
这样就算不是https，被抓包了，重复请求就会报错。

仅供参考。

#17 楼 @Rei 如果是这样的话，那楼主还需要复习下什么叫APP

#19 楼 @sefier https://en.m.wikipedia.org/wiki/App

App, apps or APP may refer to:

• Mobile app, software designed to run on smartphones and other mobile devices
• Application software that causes a computer to perform tasks for computer users
• Web application or web app, software designed to run inside a web browser

#20 楼 @Rei 按照这个定义，word 和 excel 什么的，都是 app，但是谁会这么说呢？脱离任何语境的定义，都是耍流氓。大家不是专家，都是普通人，不是都搬个字典上网的。在楼主没有特地澄清的情况下，强行解释他的 app 不是手机 app，属于臆断，所以我没必要跟你抬这个杠。

#21 楼 @sefier 楼主问 csrf，那么 web app 和 mobile app 都有可能啊，所以我问楼主有没有用 cookie 验证，因为 web app 可用也不用 cookie。是你先入为主。

补充：Ruby China 的安卓 APP 基于 turbolinks 实现，其实是 webview，需要防 csrf。

CSRF 是跨站攻击，只对普通的「网站」（当然也包括网站应用）有效。如果是不走网页访问，而是直接调用 API 的话，CSRF 本身就是无效的。CSRF 不能防止第三方直接调用接口。

看到很多人在讨论 API 安全。我觉得吧，API 具备 JWT 以及 HTTPS 就足够安全了。

#5 楼 @huacnlee

iPhone 装个证书，用 charles proxy 可以抓到 HTTPS 的。

先说结论：现代应用不需要 CSRF Token。 CSRF 攻击关键在于 cookie，如果 cookie 里不含登陆令牌，你把登录令牌放到其它 header 里就没问题。因为 CSRF 所利用的 form 和四个特殊 tag 都无法添加 header。现代应用的 API 不接受 form 提交，都是 json 风格的，现代的 web 浏览器都具备 CSP，samesite 等防范机制。CSRF 攻击排名过去十年下降了两位。具体看这个解释，如何不用 CSRF Token：https://danielw.cn/web-security-xss-csrf-cn#csrf

https://stackoverflow.com/questions/10741339/do-csrf-attacks-apply-to-apis 有类似的提问，结果是 Rest 风格的 api 项目 如果不依赖 cookies 做安全验证的话，则不需要预防 CSRF.

CSRF attacks rely on cookies being implicitly sent with all requests to a particular domain. If your API endpoints do not allow cookie-based authentication, you should be good.

APP 中加个 HTTPS 证书验证就能防止 proxy 类的解密了

楼主的问题其实是个业务问题 再严密的网络传输也会有数据被监听的可能 极端情况就是电信机房拿着你 HPPTS 的证书就可以镜像你的流量（当然这个有判头）

这个问题要拆解一下，问题 1 是 如何确保传输过程安全 问题 2 是 如何反爬 这是两回事儿 这里就不提 CSRF 了 跟楼主的实际问题不符

问题 1 用 token+HTTPS+APP 中自己做证书检验 就可以保证传输安全

问题 2 强制手机号码登录 记录访问日志 到达一定访问量直接 ban 设备 或者 不用手机号码登录 用设备码等唯一标识 从业务角度反爬 而不是从安全角度 有 N 种手段能让服务端接口觉得“请求”是从正常 APP 发过来的 所以从安全角度只能提高防护的上限 从根本上无解（魔高一尺道高一丈的逻辑）