@
phx13ye #22
遗漏有很多种可能吧，我这二把刀应该保证不了没有遗漏。
这东西应该只涉及到你期望覆盖的面的大小，没有尽头。
比如说 客户端是否要对 https 证书进行强验证（不止验证证书有效性，还要验证证书是否一致）。
比如说 时间戳+签名 需要有时间差冗余，避免时间不一致导致出错，而冗余就带来了短时间内重放的风险，此时又需要缓存若干个请求信息来防止短时间内的重放。
比如说 你的 token 机制是否足够安全，是否有吊销机制（ JWT 出来挨打）。
每个措施，一般都是对应某个场景给出的，其实还是确认场景的问题。
另外回应你附言中的问题：
content-type 是 json 的话，签名可以放进 header，也可以给 json 再罩一层 “非签名” 区域。
即：参与签名运算的只是某个子字段，而另一个子字段存储签名信息即可。
但是这里需要注意：
JSON 的 k-v 是无序的，且 JSON 序列化的格式是可以自定义的，当你期望对一个 JSON 求签名（ hash ）的时候，请务必协调好两端的 JSON 序列化格式及顺序。
如果觉得麻烦，也可以选择将需要传递的 JSON 对象，先序列化之后，存于某个 JSON String 字段。
> 对于请求，body 一般只能读取一次，读取时要先缓存一份，然后和请求首部比对
这段话我没有理解是什么意思，为什么只能读取一次。
可以考虑设置类似 “API 网关” 的概念，所有请求先经过网关的核验之后再传入业务代码。