GET 请求的安全性略低于 POST 请求。两者本身都无法提供真正的“安全”；使用 POST 请求will not神奇地使您的网站免受明显的恶意攻击。但是，使用 GET 请求can使原本安全的应用程序变得不安全。
“不得使用 GET 请求进行更改”的口头禅仍然非常有效，但这与恶意的行为。登录表单是最容易使用错误请求类型发送的表单。
搜索蜘蛛和网络加速器
这是您应该使用 POST 请求来更改数据的真正原因。搜索蜘蛛将跟踪您网站上的每个链接，但不会提交他们找到的随机表单。
网络加速器比搜索蜘蛛更糟糕，因为它们运行在客户端的计算机上，并且“单击”所有链接在登录用户的上下文中。因此，使用 GET 请求删除内容的应用程序，即使需要管理员，也会很乐意遵守（非恶意！）Web 加速器的命令，并且删除它看到的所有内容 https://web.archive.org/web/20090126045517/http://radar.oreilly.com/archives/2005/05/google-web-acce-1.html.
副攻混乱
A 混乱的副攻 http://en.wikipedia.org/wiki/Confused_deputy_problem（其中副为浏览器）是无论您使用 GET 还是 POST 请求都可以 http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx.
在攻击者控制的网站上，GET 和 POST 是同样容易提交 http://pentestmonkey.net/blog/csrf-xml-post-request 无需用户交互 http://www.javascript-coder.com/javascript-form/javascript-form-submit.phtml.
POST 不太容易受到影响的唯一情况是，许多不受攻击者控制的网站（例如第三方论坛）允许嵌入任意图像（允许攻击者注入任意 GET 请求），但阻止所有攻击注入任意 POST 请求的方法，无论是自动还是手动。
有人可能会说网络加速器是混淆代理攻击的一个例子，但这只是一个定义问题。如果有的话，恶意攻击者无法控制这一点，所以这几乎不是一个attack，即使是副手is使困惑。
代理日志
代理服务器可能会完整记录 GET URL，而不剥离查询字符串。 POST 请求参数通常不会被记录。在这两种情况下都不太可能记录 Cookie。（例子） http://www.linuxquestions.org/questions/linux-server-73/sample-squid-proxy-log-files-837345/
这是支持 POST 的一个非常无力的论据。首先，可以完整记录未加密的流量；恶意代理已经拥有它所需的一切。其次，请求参数对攻击者来说用途有限：他们真正需要的是 cookie，因此如果他们唯一拥有的就是代理日志，他们不太可能能够攻击 GET 或 POST URL。
登录请求有一个例外：这些请求往往包含用户的密码。将其保存在代理日志中会打开一个在 POST 情况下不存在的攻击向量。然而，无论如何，通过纯 HTTP 登录本质上是不安全的。
代理缓存
缓存代理可能会保留 GET 响应，但不会保留 POST 响应。尽管如此，与将 URL 转换为 POST 处理程序相比，将 GET 响应设置为不可缓存可以花费更少的精力。
HTTP“引用者”
如果用户要从响应 GET 请求而提供的页面导航到第三方网站，则该第三方网站将看到所有 GET 请求参数。
属于“向第三方泄露请求参数”类别，其严重性取决于这些参数中存在的内容。 POST 请求自然不受此影响，但是要利用 GET 请求，黑客需要将指向其自己网站的链接插入到服务器的响应中。
浏览器历史记录
这与“代理日志”参数非常相似：GET 请求与其参数一起存储在浏览器历史记录中。如果攻击者能够物理访问计算机，他们就可以轻松获取这些信息。
浏览器刷新动作
一旦用户点击“刷新”，浏览器就会重试 GET 请求。关闭后恢复选项卡时可能会这样做。因此，任何操作（例如付款）都将在没有警告的情况下重复进行。
浏览器不会在没有警告的情况下重试 POST 请求。
这是仅使用 POST 请求来更改数据的充分理由，但与恶意行为无关，因此也与安全无关。
所以我该怎么做？
- 仅使用 POST 请求来更改数据，主要是出于非安全相关的原因。
- 仅对登录表单使用 POST 请求；否则会引入攻击向量。
- 如果您的网站执行敏感操作，您确实需要一个知道自己在做什么的人，因为这无法用一个答案来涵盖。你需要使用HTTPS、HSTS、CSP，缓解SQL注入，脚本注入（XSS） http://en.wikipedia.org/wiki/Cross-site_scripting, CSRF http://en.wikipedia.org/wiki/Cross-site_request_forgery以及大量可能特定于您的平台的其他内容（例如各种框架中的批量分配漏洞：ASP.NET MVC https://web.archive.org/web/20120503215142/http://freshbrewedcode.com/joshbush/2012/03/05/mass-assignment-aspnet-mvc/, 红宝石 on Rails http://www.infoq.com/news/2012/03/GitHub-Compromised， ETC。）。没有任何一件事可以区分“安全”（不可利用）和“不安全”。
通过 HTTPS，POST 数据被编码，但 URL 是否可以被第 3 方嗅探？
不，它们不能被嗅到。但 URL 将存储在浏览器历史记录中。
公平地说，最佳实践是避免将敏感数据完全放在 POST 或 GET 中并使用服务器端代码来处理敏感信息吗？
取决于它的敏感程度，或者更具体地说，以何种方式敏感。显然客户会看到它。任何能够物理访问客户计算机的人都会看到它。客户在将其发回给您时可以对其进行欺骗。如果这些很重要，那么是的，请将敏感数据保留在服务器上，不要让它离开。
