REST API 安全问题

[gzf6]

楼主是做前端的，现在学着用 koa2 写 api 服务器，公司的后端接口一般都设计为 get 或 post 方法，很少用 put 或 delete 方法，想请教下，这两个方法有什么安全上的问题吗?

[zhengxiaowai]

没，他们不习惯用而已

[FrankFang128]

有毛安全问题，你问问他们具体是什么问题，肯定说不出来，看看 stackoverflow 就知道了
https://security.stackexchange.com/questions/38635/how-is-http-put-and-delete-methods-insecure-if-they-really-are

大概的原因是：

1. 有些傻逼后端没听过 get 和 post 之外的 verb （因为 form 表单只之处 get 和 post ），所以安全判断的时候只判断了 get 和 post，导致其他 verb 可能有安全问题（实际上就是程序员傻逼，跟 verb ）没关系。
2. 由于很多系统是不会去修复以前的漏洞的，所以干脆在 nginx 层面直接禁用 get 和 post，一了百了，呵呵（头痛医脚的典型）

程序员里面食古不化的人其实也挺多的，楼主不要被他们带偏。

[FrankFang128]

*纠正上文：因为 form 表单只支持 get 和 post

[FrankFang128]

还有傻逼面试官认为 『 post 比 get 安全』，然后把 get 也禁用了，所有 API 只允许 POST，呵呵。

[also24]

很多号称 REST API 的，其实都只是搞了个皮像肉不像的东西，假装 REST 了而已

[FrankFang128]

也不想想，如果真不安全为什么 HTTP 协议不禁用这些 verb 呢。
没逻辑的程序员我最鄙视了。

[gzf6]

@FrankFang128 啊，老哥，消消气，消消气，大过年的 😅

[version]

接口还是 post 好点.方便以后加参数也不担心转码的问题..
如果是一些接口一定不会加参数的用 get
put 主要考虑浏览器和兼容问题..因为用新的也没啥特性.还不如老套路 get post

[ala2008]

和安全没有大关系。楼上说的比较好

[springmarker]

有的防火墙会把 put 和 delete 屏蔽掉，restful 有时候也用着累

[richzhu]

@version 请问一下大佬 put delete 方法在什么情况下加了什么参数会需要转码而 post 不需要🤔

[lastpass]

本质上没有什么区别。
不过是一种规范，或者说风格上的东西。
就像你写死循环喜欢用 for(;;)或 while(true)一样

[cedoo22]

没啥区别，CRUD 完全都用 POST，纯粹是为了好管理代码而已。。。不用给业务代码打字员额外负担。

[Cbdy]

反对 @FrankFang128 的说法，请不要误导别人
在 HTTP 访问控制（ CORS ）有差异
HEAD、GET、POST 可能是简单请求，HEAD、PUT 等不是简单请求
参考
https://jianzhao.org/#/concept/http-cors
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

[gzf6]

@lastpass 嗯，我也觉得是风格问题，现在公司的后端是一个动作一个接口，api 复用率太低，我是想着一个 api 对应 get post put patch delete 这五种动作，语义上理解好一点，就是对一个 api 资源执行不同的动作。

[lsongiu]

有一次用了 delete，前端同学不会调。。。

[gzf6]

@lsongiu 嗯，可能还是得兼顾团队吧，减少沟通成本，不过还是希望团队能共同进步。

[mamtou]

新年快乐

[mozutaba]

@Cbdy 同反对，而且我就是只用 post 的。同时觉得前端到处吹的 REST API 太局限了。

[learnshare]

安全性取决于用的人，而不是 HTTP method