84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
对于前后端完全分离的网站，后端采用PHP/Java/Python向前端输出json格式的数据，而前端通过ajax向后端调用接口获取数据。这种情况下，后端的接口如果没有采取一定的保护措施是很容易被其他人恶意调用来做一些非法操作。那么，现在在这种前后端完全分离的网站架构下有哪些主流的对后端接口保护的做法？
欢迎选择我的课程，让我们一起见证您的进步~~
1）给你API的用户发放验证Key，对请求的数据内容按双方定义的规则结合Key进行编码，后端拿到请求后解码校验是否符合预期，并设置每个Key的访问频率~~内容不符合预期直接拒绝响应访问过于频繁，那么此用户在一定时间内不允许访问~~~
2）还可以发放SSH私钥/公钥的方式来保证~~~
用Access-Control-Allow-Originheader 和 csrf的token来控制。有的需要限制次数的还会在headers中加入X-RateLimit-Limit和X-RateLimit-Remaining来控制访问
Access-Control-Allow-Origin
X-RateLimit-Limit
X-RateLimit-Remaining
目前我的想法更多是限制操作频度来控制，因为无论你怎么做，会Chrome插件开发的脚本小王子总能利用你的用户体验需求绕过所有限制。
同时也建议你开放出去的api权限控制好，比如
http://api.xxx.com/customer/user/get?id=12345
不要将这个api设计为随意更换id就能查询到所有用户的信息，要在filter中对传入的id和session中维护的登录用户信息做鉴权校验。
如果这个页面被设计为不需要用户登录即可查看的偏静态页面，那我会推荐你不要用方案来实现这种页面。因为很难去做SEQ和CDN化
给你一个简单的方案：判断请求来源是不是ajax，如果不是，则拒绝请求。那么来自ajax的请求，可以进行计数，如果单位时间请求过于频繁的话，禁止请求（这样会武断的屏蔽掉一个IP后面有一家大公司的情况）。
如果是ajax的话，你根本不能判断对方是不是恶意请求，因为它很有可能真的来源于你自己的页面。
做个token验证。在前端要调用后端接口的时候，传个加密过的token过来就行啦
一般就是token，还有就是来源。。。这就杀了一片了。
做好后端验证是最重要的。传递的数据可以用js加个密，能略微增加一些抓包的难度
http协议的无状态特性决定了是无法彻底避免第三方调用你的后台服务。前面几位说的方法都有一定的作用，包括crsf、接口调用频率、用户行为分析等从某一些方面来说都是只能增加第三方调用的难度而已。
12306网站就是最好的实例。
登录数据可以用session，如果不需要登录的，可以用参数密钥时间认证。
test.php?a=1&b=2&time=12345678&code=xxxx
xxxx就是认证码，简单点可以用md5(a1b2time12345678passwd),即参数列表，加上当前时间，加上密码。你可以使用多个密码，即一个客户端一个密码，每个客户端发一个appid，即增加一个参数，
`test.php?appid=1&a=1&b=2&time=12345678&code=xxxx`，
这样可以随时修改一个客户端的密码，或者丢弃某个客户端请求。
非法访问通常使用认证来解决，方法很多session，oauth等等。对于合法的认证访问通常需要进行访问频率和次数的限制，各种API框架都有支持，比如Django restframework的throttling。对于拒绝服务时的访问，通常需要在更前端做控制，比如在nginx上配置rate limit。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1）给你API的用户发放验证Key，对请求的数据内容按双方定义的规则结合Key进行编码，后端拿到请求后解码校验是否符合预期，并设置每个Key的访问频率~~
内容不符合预期直接拒绝响应
访问过于频繁，那么此用户在一定时间内不允许访问~~~
2）还可以发放SSH私钥/公钥的方式来保证~~~
用
Access-Control-Allow-Originheader 和 csrf的token来控制。有的需要限制次数的还会在headers中加入
X-RateLimit-Limit和X-RateLimit-Remaining来控制访问目前我的想法更多是限制操作频度来控制，因为无论你怎么做，会Chrome插件开发的脚本小王子总能利用你的用户体验需求绕过所有限制。
同时也建议你开放出去的api权限控制好，比如
不要将这个api设计为随意更换id就能查询到所有用户的信息，要在filter中对传入的id和session中维护的登录用户信息做鉴权校验。
如果这个页面被设计为不需要用户登录即可查看的偏静态页面，那我会推荐你不要用方案来实现这种页面。因为很难去做SEQ和CDN化
给你一个简单的方案：判断请求来源是不是ajax，如果不是，则拒绝请求。那么来自ajax的请求，可以进行计数，如果单位时间请求过于频繁的话，禁止请求（这样会武断的屏蔽掉一个IP后面有一家大公司的情况）。
如果是ajax的话，你根本不能判断对方是不是恶意请求，因为它很有可能真的来源于你自己的页面。
做个token验证。在前端要调用后端接口的时候，传个加密过的token过来就行啦
一般就是token，还有就是来源。。。这就杀了一片了。
做好后端验证是最重要的。
传递的数据可以用js加个密，能略微增加一些抓包的难度
http协议的无状态特性决定了是无法彻底避免第三方调用你的后台服务。前面几位说的方法都有一定的作用，包括crsf、接口调用频率、用户行为分析等从某一些方面来说都是只能增加第三方调用的难度而已。
12306网站就是最好的实例。
登录数据可以用session，如果不需要登录的，可以用参数密钥时间认证。
xxxx就是认证码，简单点可以用md5(a1b2time12345678passwd),即参数列表，加上当前时间，加上密码。你可以使用多个密码，即一个客户端一个密码，每个客户端发一个appid，即增加一个参数，
这样可以随时修改一个客户端的密码，或者丢弃某个客户端请求。
非法访问通常使用认证来解决，方法很多session，oauth等等。
对于合法的认证访问通常需要进行访问频率和次数的限制，各种API框架都有支持，比如Django restframework的throttling。
对于拒绝服务时的访问，通常需要在更前端做控制，比如在nginx上配置rate limit。