我应该使用GET或POST来检索敏感数据，因为：
RFC 2616，对我而言，并没有为我澄清这一点：
当然，无法确保服务器不会因执行
GET请求而产生副作用;实际上，一些动态资源会考虑这个功能。这里的重要区别是用户没有请求副作用，因此不能对他们负责。 [...]
答案 0 :(得分：8)
首先，RFC 2616 已过时。因此，它不应再被用作参考。
您将在下面找到HTTP / 1.1协议的当前参考资料：
查看RFC 7231关于安全方法的内容：
考虑请求方法＆＃34;安全＆＃34;如果他们定义的语义是 基本上只读;即，客户没有请求，并且确实如此 不要指望，原因服务器上的状态发生了任何变化 将安全方法应用于目标资源。 [...]
安全方法的这一定义并不妨碍实施 包括可能有害的行为，但事实并非如此 完全只读，或在调用保险箱时引起副作用 方法。 然而，重要的是客户没有 请求其他行为，不能追究其责任 它。例如，大多数服务器都会附加请求信息以进行访问 每个响应完成时记录文件，不管是什么 方法，即使日志存储可能会被认为是安全的 变满并崩溃服务器。 [...]
在本规范定义的请求方法中，
GET，HEAD，OPTIONS和TRACE方法被定义为安全的。 [...]
在HTTP方法的上下文中， safe 与安全性无关，并且以类似的方式，安全与您处理敏感数据的方式无关。 安全意味着只读。
如上所述，使用安全方法不会阻止您执行非只读操作，例如将请求记录到文件中。但是，此操作对于客户端应该是透明的。
这取决于您正在执行的操作。在REST API中，POST方法经常用于创建资源，而GET方法经常用于请求资源的表示。
如果您想通过网络发送敏感数据时确保安全，请使用 HTTPS ，并且不要在网址中公开敏感数据（例如密码）。
答案 1 :(得分：4)
除Cássio Mazzochi Molin's excellent answer外，您应该使用HTTPS，但您应该（通常）使用：
检索时使用GET的原因是该操作没有副作用，因此没有理由使用POST。之前使用POST的唯一原因是在通过AJAX检索JSON时，因为旧浏览器有错误意味着用户在浏览器中打开的另一个域可能使用<script>标记从JSON窃取数据（JSON Hijacking） ）。禁止GET可防止此攻击，因为<script src="...">始终使用GET方法。见this answer。请注意，在此处使用POST意味着您应该为此方法禁用GET服务器端。
使用POST发送敏感数据的原因是它可以防止数据通过查询字符串泄漏（尽管另一种方法是使用GET设置自定义标头，尽管POST更有意义）。原因是URL中的查询字符串数据由代理服务器记录，默认情况下由服务器日志记录，也可以存储在浏览器历史记录中，这使得它不是传输个人或其他敏感细节的好地方。请注意，在通过HTTPS传输期间，它们将被加密，只是它们可以从加密状态泄漏到其他非加密或非受控位置。当然，返回RFC 7231，如果您根据此发送的敏感数据进行更改，则POST更好，因为它会阻止浏览器在大多数情况下意外地再次发送它。 / p>
答案 2 :(得分：0)
我建议使用POST，不是出于任何真正的技术原因，如副作用，而是因为服务器通常配置为更多地观看POST调用，而许多现成的安全模块将POST视为操作发生的地方
这不是一个很好的技术原因，但我会对看到其他人的想法感兴趣。
答案 3 :(得分：0)
您应该使用GET从服务器检索信息。
审核和日志记录不会被视为副作用，因为它们对客户端是透明的。
可以使用SSL和“Cache-control：no-store”来保护响应数据。一旦敏感数据传到客户端，就没有办法阻止他们用它做任何他们想做的事情。
答案 4 :(得分：0)
使用POST仅作为旨在防止用户拒绝接收响应的应用程序的一部分才有意义。我不知道任何此类方案，我不会冒险设计一个我的头顶。
用户请求的目的不是创建审计日志条目;目的是得到回应。问责日志是副作用，但它对用户是隐藏的，因此不需要POST。
换句话说，您不能让用户对获取数据负责，因为您无法证明他们已收到数据。但是知道谁请求数据可能有助于调查，因此将其记录为副作用仍然有用。
答案 5 :(得分：0)
如果数据非常敏感，请考虑使用POST。很容易在没有太多考虑的情况下发出GET请求 - 例如，如果有人在使用适当的权限登录到应用程序时查看日志文件并且他们单击链接，则会生成get请求。
您可以要求客户构建一个可以称为“敏感数据访问请求”的文档。您可能需要一个字段来查看此数据。服务器可以接收此请求并发送敏感数据作为响应。
根据用户有权访问的客户端应用程序的类型，如果用户发送POST请求而不是发送GET请求，则表示意向性可能要容易得多。