当比较HTTP GET和HTTP POST时，从安全角度看有什么不同?其中一个选择是否天生就比另一个更安全?如果有，为什么?
我意识到POST没有公开URL上的信息，但其中有任何真正的价值吗?或者它只是通过隐匿性来实现安全?当安全性是一个问题时，我是否有理由更喜欢POST ?
编辑: 通过HTTPS, POST数据被编码，但url会被第三方嗅探吗?此外，我正在处理JSP;当使用JSP或类似的框架时，是否可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而是使用服务器端代码来处理敏感信息?
当前回答
我不打算重复所有其他的答案，但有一个方面我还没有看到提到——那就是数据消失的故事。我不知道去哪里找，但是…
基本上，它是关于一个网络应用程序，每隔几晚就会神秘地丢失所有数据，而且没有人知道原因。检查日志后发现，该网站是由谷歌或其他任意蜘蛛找到的，它很高兴地GET(读:GET)它在网站上找到的所有链接——包括“删除此条目”和“你确定吗?”链接。
事实上，部分已经提到了。这就是“不要在GET上而只在POST上更改数据”背后的故事。爬虫会很高兴地遵循GET，而不是POST。即使robots.txt也不能帮助对抗行为不当的爬虫。
其他回答
就安全性而言，它们本质上是相同的。虽然POST确实不通过URL公开信息，但它在客户机和服务器之间的实际网络通信中公开的信息与GET一样多。如果需要传递敏感信息，那么第一道防线就是使用Secure HTTP传递。
GET或查询字符串帖子对于标记特定项目或协助搜索引擎优化和索引项目所需的信息非常有用。
POST适用于用于提交一次性数据的标准表单。我不会使用GET来发布实际的表单，除非在搜索表单中，您希望允许用户将查询保存在书签中，或者类似的东西。
除非使用https，否则不存在安全性—使用https, GET和POST之间的传输安全性是相同的。
但是一个重要的方面是客户机和服务器在记住请求时的区别。在考虑使用GET或POST进行登录时，要记住这一点非常重要。
使用POST，密码由服务器应用程序处理，然后丢弃，因为一个好的设计不会在数据库中存储密码——只存储加密安全的散列。
但是使用GET，服务器日志最终将包含包含查询参数的请求。因此，无论数据库中的密码哈希值有多好，服务器日志仍然会以明文形式包含密码。除非对文件系统进行加密，否则即使在删除日志文件之后，服务器磁盘仍将包含这些密码。
使用访问令牌作为查询参数时也会出现同样的问题。这也是为什么考虑在HTTP报头数据中提供任何访问令牌是有意义的原因——比如在授权报头中使用承载令牌。
服务器日志通常是web服务中最薄弱的部分，允许攻击者从泄露的信息中提升他们的访问权限。
这是一篇旧文章，但我想反对其中的一些答案。如果要传输敏感数据，则需要使用SSL。如果您使用带有GET参数的SSL(例如?userid=123)，该数据将以纯文本形式发送!如果使用POST发送，则将值放在消息的加密正文中，因此大多数MITM攻击都无法读取。
最大的区别在于数据传递的位置。如果数据放在URL中，就不能加密，否则就无法路由到服务器，因为只有你可以读取URL。这就是GET的工作方式。
简而言之，您可以在POST中通过SSL安全地传输数据，但您不能使用GET，无论是否使用SSL。
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最初的含义。
修改POST请求更加困难(它需要比编辑查询字符串更多的努力)。编辑:换句话说，它只是通过模糊来保证安全，而且几乎不是这样。
