English 将HTTP GET与HTTP POST进行比较时，从安全角度来看有什么区别？这些选择之一在本质上比其他选择更安全吗？如果是这样，为什么？
我意识到POST不会在URL上公开信息，但是其中有什么真正的价值，还是仅仅是通过隐蔽性实现安全性？当出于安全考虑时，是否有理由我应该选择POST？
编辑：
通过HTTPS，对POST数据进行了编码，但是URL是否可以被第三方监听？另外，我正在处理JSP；当使用JSP或类似框架时，可以公平地说，最佳实践是避免将敏感数据完全放在POST或GET中，而使用服务器端代码来处理敏感信息吗？
免责声明：以下几点仅适用于API调用，不适用于网站URL。
网络安全性：您必须使用HTTPS。在这种情况下，GET和POST同样安全。
浏览器历史记录：对于诸如Angular JS，React JS等前端应用程序，API调用是由前端进行的AJAX调用。这些不会成为浏览器历史记录的一部分。因此，POST和GET同样安全。
服务器端日志：使用数据屏蔽和访问日志格式的写集，可以从request-URL隐藏所有或仅敏感数据。
浏览器控制台中的数据可见性：对于有恶意的人来说，查看POST数据和获取GET几乎一样。
因此，通过正确的日志记录做法，GET API与POST API一样安全。随处进行POST，会导致API定义不正确，应避免使用。
这是一篇旧文章，但我想反对一些答案。如果要传输敏感数据，则需要使用SSL。如果您将SSL与GET参数一起使用（例如？userid = 123），则该数据将以纯文本格式发送！如果使用POST发送，则这些值将放入消息的加密主体中，因此对于大多数MITM攻击都不可读。
最大的区别是数据传递的位置。仅在将数据放置在URL中时才有意义，否则将无法对其进行加密，否则您将无法路由到服务器，因为只有您才能读取URL。这就是GET的工作方式。
简而言之，您可以通过POST安全地通过SSL传输数据，但是不能通过GET（无论是否使用SSL）来传输数据。
与SSL一起安装，Post是最安全的，因为它在邮件正文中传输。
但是所有这些方法都是不安全的，因为其下面使用的7位协议很容易被擒纵。即使通过4级Web应用程序防火墙。
套接字也不能保证...即使它在某些方面更安全。
POST的安全性较差的一个原因是，默认情况下记录GET，参数和所有数据几乎都由您的Web服务器记录。
POST是相反的，它几乎普遍不记录，从而导致很难发现攻击者的活动。
我不赞成“它太大”的说法，这也就没有理由不记录任何东西，至少1KB，对于人们发现攻击者在较弱的入口点工作直到它弹出之前大有帮助。通过启用任何基于HTTP的后门以静默方式传递无限量的数据，从而实现双重保护。
区别在于GET发送的数据处于打开状态，而POST则处于隐藏状态（位于http标头中）。
因此，对于非安全数据（例如Google中的查询字符串），get会更好。身份验证数据绝不能通过GET发送-因此请在此处使用POST。当然，整个主题要复杂一些。如果您想了解更多信息，请阅读这篇文章（德语）。
最近发布了一种攻击，该攻击允许一个中间人泄露被压缩HTTPS请求的请求主体。由于请求标头和URL不会通过HTTP压缩，因此可以更好地保护GET请求免受这种特殊攻击。
在某些模式下，GET请求也容易受到攻击，SPDY压缩请求标头，TLS还提供可选的（很少使用）压缩。在这些情况下，更容易防止攻击（浏览器供应商已提供了修复程序）。HTTP级别压缩是更基本的功能，供应商不太可能会禁用它。
这只是一个示例，它显示了GET比POST更安全的情况，但是从这种攻击原因出发，选择GET而不是POST并不是一个好主意。攻击非常复杂，并且要求先决条件（攻击者必须能够控制部分请求内容）。在攻击可能有害的情况下，最好禁用HTTP压缩。
就像以前有人说过的那样，HTTPS带来了安全性。
但是，POST比GET安全一些，因为GET可以存储在历史记录中。
但是，更不幸的是，有时POST或GET的选择不取决于开发人员。例如，超链接始终由GET发送（除非使用javascript将其转换为帖子形式）。
RFC7231：
即使在URI标识安全资源的情况下，也希望它们被共享而不是安全的。URI通常显示在显示器上，在打印页面时将其添加到模板中，并存储在各种不受保护的书签列表中。因此，不建议包含URI URI中的敏感信息，个人身份信息或存在泄露风险的信息。
服务的作者应避免基于GET的表单提交敏感数据，因为该数据将被放置在请求目标中。许多现有的服务器，代理和用户代理会在第三方可能可见的位置记录或显示请求目标。这些服务应改为使用基于POST的表单提交。”
该RFC明确规定，不应使用GET提交敏感数据。因此，某些实现者可能不会同样谨慎地处理从GET请求的查询部分获得的数据。我自己正在研究一种确保数据完整性的协议。根据此规范，我不必保证GET数据的完整性（因为没有人遵守这些规范，所以我会这样做）
GET对任何人都是可见的（甚至现在就在您的肩膀上），并且保存在缓存中，因此不确定使用post的安全性，不确定没有某些加密例程的btw post，出于安全性的考虑，您必须使用SSL（ https）
更改POST请求比较困难（比编辑查询字符串需要更多的精力）。编辑：换句话说，这只是出于默默无闻的安全，而几乎没有。
我不想重复所有其他答案，但是有一个我尚未提及的方面-这是数据消失的故事。我不知道在哪里可以找到，但是...
基本上，它是关于一个Web应用程序，每隔几个晚上就会神秘地释放所有数据，而没人知道为什么。后来检查日志发现，该网站是由google或其他任意蜘蛛发现的，它很高兴地GET（读取：GOT）在该网站上找到的所有链接-包括“删除此条目”和“您确定吗？” 链接。
实际上-已经提到了其中的一部分。这就是“不要在GET上更改数据，而只能在POST上更改数据”背后的故事。抓取者会很乐意遵循GET，而不是POST。甚至robots.txt也无助于防止抓取工具行为异常。
您还应该注意，如果您的站点包含到其他外部站点的链接，则您在按下外部站点上的链接时不会使用GET将其放入外部站点的Refererer标头中。因此，通过GET方法传输登录数据始终是一个大问题。因为那样可以通过仅查看日志或查看Google Analytics（分析）（或类似数据）来公开登录凭据，以便于访问。
许多人采用了一个约定（罗斯所禁止的约定），即GET请求仅检索数据，而不修改服务器上的任何数据，而POST请求用于所有数据修改。虽然一个是不固有的安全性比其他的，如果你做到遵守这个约定，你可以申请跨部门的安全逻辑（例如仅拥有帐户可以修改数据，因此未经验证的职位是拒绝）。
安全性是过渡中数据的安全性：POST和GET之间没有区别。
作为计算机上数据安全的安全性：POST更安全（无URL历史记录）
除非您定义要防止的安全性，否则安全性概念毫无意义。
如果要保护存储的浏览器历史记录，某些类型的日志记录以及查看您的URL的人的安全，则POST更安全。
如果您想防止有人嗅探您的网络活动，那没有什么区别。
两者都没有神奇地赋予请求安全性，但是GET隐含一些副作用，通常会阻止它的安全性。
GET URL显示在浏览器历史记录和网络服务器日志中。因此，切勿将它们用于登录表单和信用卡号之类的东西。
但是，仅发布该数据也不能保证其安全性。为此，您需要SSL。通过HTTP使用时，GET和POST均以有线方式以纯文本形式发送数据。
POST数据还有其他很好的理由-例如提交无限数量的数据或向临时用户隐藏参数的功能。
缺点是用户无法为通过POST发送的查询结果添加书签。为此，您需要GET。
我通常的选择方法是：
考虑这种情况：松散的API接受GET请求，例如：
http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1
在某些设置中，当您请求此URL时，如果对该请求有错误/警告，则整行都将记录在日志文件中。更糟糕的是：如果您忘记在生产服务器中禁用错误消息，则此信息仅在浏览器中以纯文本显示！现在，您已经将API密钥提供给了所有人。
不幸的是，真正的API是以这种方式工作的。
我不希望在日志中包含一些敏感信息或在浏览器中显示它们。POST和GET不一样。在适当的地方使用每个。
这与安全性无关，但是... 浏览器不会缓存POST请求。
GET和POST之间的区别不应该从安全性角度考虑，而应从它们对服务器的意图来看。GET绝不应更改服务器上的数据-至少不更改日志中的数据-但POST可以创建新资源。
好的代理不会缓存POST数据，但是它们可以缓存URL中的GET数据，因此您可以说POST应该更安全。但是POST数据仍可用于性能不好的代理。
如许多答案中所述，唯一确定的选择是通过SSL。
但是，请确保GET方法不会提交任何更改，例如删除数据库行等。
The GET request is marginally less secure than the POST request. Neither offers true "security" by itself; using POST requests will not magically make your website secure against malicious attacks by a noticeable amount. However, using GET requests can make an otherwise secure application insecure.
The mantra that you "must not use GET requests to make changes" is still very much valid, but this has little to do with malicious behaviour. Login forms are the ones most sensitive to being sent using the wrong request type.
This is the real reason you should use POST requests for changing data. Search spiders will follow every link on your website, but will not submit random forms they find.
Web accelerators are worse than search spiders, because they run on the client’s machine, and "click" all links in the context of the logged in user. Thus, an application that uses a GET request to delete stuff, even if it requires an administrator, will happily obey the orders of the (non-malicious!) web accelerator and delete everything it sees.
A confused deputy attack (where the deputy is the browser) is possible regardless of whether you use a GET or a POST request.
On attacker-controlled websites GET and POST are equally easy to submit without user interaction.
The only scenario in which POST is slightly less susceptible is that many websites that aren’t under the attacker’s control (say, a third-party forum) allow embedding arbitrary images (allowing the attacker to inject an arbitrary GET request), but prevent all ways of injecting an arbitary POST request, whether automatic or manual.
One might argue that web accelerators are an example of confused deputy attack, but that’s just a matter of definition. If anything, a malicious attacker has no control over this, so it’s hardly an attack, even if the deputy is confused.
Proxy servers are likely to log GET URLs in their entirety, without stripping the query string. POST request parameters are not normally logged. Cookies are unlikely to be logged in either case. (example)
This is a very weak argument in favour of POST. Firstly, un-encrypted traffic can be logged in its entirety; a malicious proxy already has everything it needs. Secondly, the request parameters are of limited use to an attacker: what they really need is the cookies, so if the only thing they have are proxy logs, they are unlikely to be able to attack either a GET or a POST URL.
There is one exception for login requests: these tend to contain the user’s password. Saving this in the proxy log opens up a vector of attack that is absent in the case of POST. However, login over plain HTTP is inherently insecure anyway.
Caching proxies might retain GET responses, but not POST responses. Having said that, GET responses can be made non-cacheable with less effort than converting the URL to a POST handler.
If the user were to navigate to a third party website from the page served in response to a GET request, that third party website gets to see all the GET request parameters.
Belongs to the category of "reveals request parameters to a third party", whose severity depends on what is present in those parameters. POST requests are naturally immune to this, however to exploit the GET request a hacker would need to insert a link to their own website into the server’s response.
This is very similar to the "proxy logs" argument: GET requests are stored in the browser history along with their parameters. The attacker can easily obtain these if they have physical access to the machine.
The browser will retry a GET request as soon as the user hits "refresh". It might do that when restoring tabs after shutdown. Any action (say, a payment) will thus be repeated without warning.
The browser will not retry a POST request without a warning.
This is a good reason to use only POST requests for changing data, but has nothing to do with malicious behaviour and, hence, security.
Over HTTPS, POST data is encoded, but could URLs be sniffed by a 3rd party?
No, they can’t be sniffed. But the URLs will be stored in the browser history.
Would it be fair to say the best practice is to avoid possible placing sensitive data in the POST or GET altogether and using server side code to handle sensitive information instead?
Depends on how sensitive it is, or more specifically, in what way. Obviously the client will see it. Anyone with physical access to the client’s computer will see it. The client can spoof it when sending it back to you. If those matter then yes, keep the sensitive data on the server and don’t let it leave.
GET和POST中的任何一个都不比另一个固有地“更安全”，就像传真和电话中的任何一个都不比另一个更“安全”。提供了各种HTTP方法，因此您可以选择一种最适合您要解决的问题的方法。GET更适合幂等查询，而POST更适合“动作”查询，但是如果您不了解要维护的应用程序的安全体系结构，则可以轻松地与任何人相处。
最好阅读第9章：HTTP / 1.1 RFC的方法定义，以全面了解GET和POST最初的含义。
没有增加的安全性。
发布数据不会显示在历史记录和/或日志文件中，但是如果应确保数据安全，则需要SSL。
否则，嗅探导线的任何人都可以读取您的数据。
对于登录表单或任何其他具有相对敏感信息的表单，即使POST与相比并没有带来真正的安全优势GET，也请确保您使用的POST身份如下：
POSTed将不会保存在用户的历史记录中。GET，它将在历史记录和URL栏中可见）。而且，GET对数据有理论上的限制。POST没有。
有关真实的敏感信息，请确保使用SSL（HTTPS）
就安全性而言，它们本质上是相同的。的确，POST不会通过URL公开信息，但是它在客户机与服务器之间的实际网络通信中公开的信息与GET一样多。如果您需要传递敏感信息，那么第一道防线就是使用安全HTTP传递信息。
GET或查询字符串文章确实非常适合为特定项目添加书签或协助搜索引擎优化和索引项目所需的信息。
POST适用于用于提交一次数据的标准表格。我不会使用GET来发布实际的表单，除非您可能希望在搜索表单中允许用户将查询保存在书签中或类似内容中，否则我不会使用GET。
甚至POST也接受GET请求。假设您有一个表单，其中包含诸如user.name和user.passwd之类的输入，这些输入应该支持用户名和密码。如果我们仅添加？user.name =“我的用户＆user.passwd =”我的密码“，则将通过“绕过登录页面”来接受请求。
A solution for this is to implement filters (java filters as an e) on server side and detect no string queries are passed as GET arguments.