RFC7231:

uri的目的是共享的，而不是安全的，即使它们被识别 获取资源。uri通常显示在添加到的显示器上 模板当一个页面被打印出来，并存储在各种 未受保护的书签列表。因此，包括 URI中的敏感信息、个人身份信息、 或者是要暴露的风险。

服务的作者应该避免在提交时使用基于get的表单 敏感数据，因为这些数据将放在 请求目标。许多现有的服务器、代理和用户代理都有日志记录 或者将请求目标显示在可以看到它的地方 第三方。这样的服务应该使用基于post的表单提交 相反。”

这个RFC明确指出不应该使用GET提交敏感数据。由于这句话，一些实现者可能不会同样小心地处理从GET请求的查询部分获得的数据。我自己也在研究一个保证数据完整性的协议。根据这个规范，我不应该保证GET数据的完整性(我将这样做，因为没有人遵守这些规范)

修改POST请求更加困难(它需要比编辑查询字符串更多的努力)。编辑:换句话说，它只是通过模糊来保证安全，而且几乎不是这样。

这两种方法都不能神奇地为请求提供安全性，但是GET暗示了一些副作用，这些副作用通常会阻止请求的安全性。

GET url显示在浏览器历史记录和web服务器日志中。因此，永远不要将它们用于登录表单和信用卡号之类的内容。

然而，仅仅发布这些数据也不能保证它的安全。为此，您需要SSL。当通过HTTP使用时，GET和POST都以明文形式通过网络发送数据。

POST数据还有其他很好的理由——比如可以提交无限量的数据，或者对普通用户隐藏参数。

缺点是用户不能收藏通过POST发送的查询结果。为此，您需要GET。

我不打算重复所有其他的答案，但有一个方面我还没有看到提到——那就是数据消失的故事。我不知道去哪里找，但是…

基本上，它是关于一个网络应用程序，每隔几晚就会神秘地丢失所有数据，而且没有人知道原因。检查日志后发现，该网站是由谷歌或其他任意蜘蛛找到的，它很高兴地GET(读:GET)它在网站上找到的所有链接——包括“删除此条目”和“你确定吗?”链接。

事实上，部分已经提到了。这就是“不要在GET上而只在POST上更改数据”背后的故事。爬虫会很高兴地遵循GET，而不是POST。即使robots.txt也不能帮助对抗行为不当的爬虫。

考虑一下这种情况:一个草率的API接受如下GET请求:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

在某些设置中，当您请求此URL时，如果有关于请求的错误/警告，则整行内容将记录在日志文件中。更糟糕的是:如果您忘记禁用生产服务器中的错误消息，则此信息将在浏览器中显示!现在你已经把你的API密钥给了所有人。

不幸的是，有一些真正的API是这样工作的。

我不喜欢在日志中有一些敏感信息或在浏览器中显示它们的想法。POST和GET是不同的。在适当的地方使用它们。

Neither one of GET and POST is inherently "more secure" than the other, just like neither one of fax and phone is "more secure" than the other. The various HTTP methods are provided so that you can choose the one which is most appropiate for the problem you're trying to solve. GET is more appropiate for idempotent queries while POST is more appropiate for "action" queries, but you can shoot yourself in the foot just as easily with any of them if you don't understand the security architecture for the application you're maintaining.

最好是阅读第9章:HTTP/1.1 RFC的方法定义，以全面了解get和POST最初的含义。