在比较 HTTP GET 和 HTTP POST 时，从安全角度来看有什么区别？其中一种选择本质上是否比另一种更安全？如果是这样，为什么？
我意识到 POST 不会公开 URL 上的信息，但是这是否有任何真正的价值，或者它只是通过默默无闻的安全性？当担心安全性时，我是否有理由更喜欢 POST？
编辑：
通过 HTTPS，POST 数据被编码，但是 URL 可以被第三方嗅探吗？此外，我正在处理 JSP；在使用 JSP 或类似框架时，是否可以说最佳做法是完全避免将敏感数据放在 POST 或 GET 中，而是使用服务器端代码来处理敏感信息？
GET 请求的安全性略低于 POST 请求。两者都不能单独提供真正的“安全”；使用 POST 请求不会神奇地使您的网站在相当大的程度上防止恶意攻击。但是，使用 GET 请求会使原本安全的应用程序变得不安全。
您“不得使用 GET 请求进行更改”的口头禅仍然非常有效，但这与恶意行为无关。登录表单是最容易使用错误请求类型发送的表单。
这是您应该使用 POST 请求来更改数据的真正原因。搜索蜘蛛会跟踪您网站上的每个链接，但不会提交他们找到的随机表单。
Web 加速器比搜索蜘蛛更糟糕，因为它们在客户端机器上运行，并“点击”登录用户上下文中的所有链接。因此，使用 GET 请求删除内容的应用程序，即使它需要管理员，也会很乐意服从（非恶意！）网络加速器的命令并删除它看到的所有内容。
无论您使用 GET 还是 POST 请求，都可能发生混淆代理攻击（其中代理是浏览器）。
在攻击者控制的网站上，GET 和 POST同样容易提交 ，无需用户交互。
POST 不太容易受到影响的唯一情况是，许多不受攻击者控制的网站（例如，第三方论坛）允许嵌入任意图像（允许攻击者注入任意 GET 请求），但阻止所有注入任意 POST 请求的方法，无论是自动还是手动。
有人可能会争辩说，网络加速器是混淆代理攻击的一个例子，但这只是定义问题。如果有的话，恶意攻击者无法控制这一点，因此即使副手感到困惑，也几乎不是攻击。
代理服务器可能会完整记录 GET URL，而不剥离查询字符串。POST 请求参数通常不会被记录。在这两种情况下都不太可能记录 Cookie。（例子）
这是支持 POST 的一个非常弱的论点。首先，可以完整记录未加密的流量；恶意代理已经拥有它需要的一切。其次，请求参数对攻击者的用途有限：他们真正需要的是 cookie，所以如果他们只有代理日志，他们不太可能攻击 GET 或 POST URL。
登录请求有一个例外：这些请求往往包含用户的密码。将其保存在代理日志中会打开一个在 POST 情况下不存在的攻击向量。但是，无论如何，通过普通 HTTP 登录本质上是不安全的。
缓存代理可能会保留 GET 响应，但不会保留 POST 响应。话虽如此，与将 URL 转换为 POST 处理程序相比，GET 响应可以变得不可缓存。
如果用户要从响应 GET 请求而提供的页面导航到第三方网站，则该第三方网站将看到所有 GET 请求参数。
属于“向第三方显示请求参数”的类别，其严重程度取决于这些参数中存在的内容。POST 请求自然不受此影响，但是为了利用 GET 请求，黑客需要将指向他们自己网站的链接插入到服务器的响应中。
这与“代理日志”参数非常相似：GET 请求与其参数一起存储在浏览器历史记录中。如果攻击者可以物理访问机器，他们可以轻松获得这些。
一旦用户点击“刷新”，浏览器就会重试 GET 请求。关机后恢复选项卡时可能会这样做。因此，任何行动（例如，付款）都将在没有警告的情况下重复。
浏览器不会在没有警告的情况下重试 POST 请求。
这是仅使用 POST 请求来更改数据的一个很好的理由，但与恶意行为无关，因此与安全性无关。
通过 HTTPS，POST 数据被编码，但是 URL 可以被第三方嗅探吗？
不，它们不能被嗅探。但 URL 将存储在浏览器历史记录中。
公平地说，最好的做法是避免将敏感数据完全放在 POST 或 GET 中，而是使用服务器端代码来处理敏感信息吗？
取决于它的敏感程度，或者更具体地说，以何种方式敏感。显然客户会看到它。任何可以物理访问客户计算机的人都会看到它。客户可以在将其发回给您时对其进行欺骗。如果这些很重要，那么可以，将敏感数据保留在服务器上，不要让它离开。
就安全性而言，它们本质上是相同的。虽然 POST 确实不会通过 URL 公开信息，但它在客户端和服务器之间的实际网络通信中公开的信息与 GET 一样多。如果您需要传递敏感信息，您的第一道防线将是使用安全 HTTP 传递它。
GET 或查询字符串帖子非常适合为特定项目添加书签或协助搜索引擎优化和索引项目所需的信息。
POST 适用于用于提交一次性数据的标准表单。我不会使用 GET 来发布实际表单，除非可能在您希望允许用户将查询保存在书签中的搜索表单中，或者类似的东西。
您没有提供更高的安全性，因为通过 HTTP POST 发送的变量比通过 HTTP GET 发送的变量要高。
<html>
<body>
<form action="http://example.com" method="get">
User: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="hidden" name="extra" value="lolcatz" />
<input type="submit"/>
</form>
</body>
</html>
你的浏览器问什么？它问这个：
GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
Host: example.com
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
POST / HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Length: 49
Cache-Control: max-age=0
Origin: null
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
username=swordfish&password=hunter2&extra=lolcatz
这两个HTTP 请求都是：
许多浏览器不支持除 POST/GET 之外的 HTTP 方法。
许多浏览器行为存储页面地址，但这并不意味着您可以忽略任何其他问题。
所以具体来说：
一个本质上比另一个更安全吗？我意识到 POST 不会公开 URL 上的信息，但其中是否有任何真正的价值，或者它只是通过默默无闻的安全性？这里的最佳做法是什么？
这是正确的，因为你用来说 HTTP 的软件倾向于使用一种方法而不是另一种方法来存储请求变量，这只会阻止某人查看你的浏览器历史记录或来自 10 岁认为他们理解 h4x0r1ng 的其他一些天真的攻击，或检查您的历史存储的脚本。如果您有一个可以检查您的历史存储的脚本，那么您也可以轻松地拥有一个检查您的网络流量的脚本，所以通过默默无闻的整个安全性只是为脚本小子和嫉妒的女朋友提供了默默无闻。
通过 https，POST 数据被编码，但 url 可以被第三方嗅探吗？
以下是 SSL 的工作原理。还记得我上面发送的那两个请求吗？这是它们在 SSL 中的样子：（我将页面更改为https://encrypted.google.com/因为 example.com 对 SSL 没有响应）。
q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r
rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv
（注意：我将 HEX 转换为 ASCII，其中一些显然不应该显示）
整个 HTTP 会话都是加密的，唯一可见的通信部分是在 TCP/IP 层（即 IP 地址和连接端口信息）。
POST 唯一的安全措施是什么？防止您嫉妒的前任翻阅您的浏览器历史记录。就是这样。世界其他地方登录到您的帐户嘲笑您。
为了进一步说明为什么 POST 不安全，Facebook 到处使用 POST 请求，那么FireSheep 之类的软件怎么会存在呢？
请注意，即使您使用 HTTPS 并且您的站点不包含XSS漏洞，您也可能会受到CSRF攻击。简而言之，这种攻击场景假定受害者（您的站点或服务的用户）已经登录并拥有适当的 cookie，然后请求受害者的浏览器对您的（假定是安全的）站点执行某些操作。如果您没有针对 CSRF 的保护，攻击者仍然可以使用受害者凭据执行操作。攻击者看不到服务器响应，因为它会被传输到受害者的浏览器，但损坏通常在那个时候已经造成。
没有额外的安全性。
发布数据不会显示在历史记录和/或日志文件中，但如果数据应该保持安全，则需要 SSL。
否则，任何嗅探电线的人都可以读取您的数据。
即使POST与 , 对于登录表单或任何其他具有相对敏感信息的表单相比没有真正的安全优势GET，请确保您使用POST的是：
POST不会保存在用户的历史记录中。GET，将在历史记录和 URL 栏中可见）。此外，GET具有数据的理论限制。POST没有。
对于真正的敏感信息，请务必使用SSL( HTTPS)
GET 和 POST 都不比另一个“更安全”，就像传真和电话都不比另一个“更安全”一样。提供了各种 HTTP 方法，以便您可以选择最适合您要解决的问题的方法。GET 更适合幂等查询，而 POST 更适合“动作”查询，但如果您不了解您正在维护的应用程序的安全架构，您可以很容易地使用它们中的任何一个。
最好阅读第 9 章： HTTP/1.1 RFC的方法定义，以全面了解 GET 和 POST 最初设想的含义。
GET 和 POST 之间的区别不应该从安全性的角度来看待，而应该从它们对服务器的意图来看。GET 永远不应该改变服务器上的数据——至少除了日志之外——但是 POST 可以创建新的资源。
好的代理不会缓存 POST 数据，但它们可能会缓存来自 URL 的 GET 数据，因此您可以说 POST 应该更安全。但 POST 数据仍可用于表现不佳的代理。
正如许多答案中提到的，唯一确定的赌注是通过 SSL。
但请确保 GET 方法不会提交任何更改，例如删除数据库行等。
这与安全无关，但是...浏览器不缓存 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 请求更难（它比编辑查询字符串需要更多的努力）。编辑：换句话说，它只是默默无闻的安全，几乎没有。
安全性作为传输中数据的安全性：POST 和 GET 之间没有区别。
安全作为计算机上数据的安全：POST 更安全（没有 URL 历史记录）
除非您定义要保护的是什么，否则安全性的概念是没有意义的。
如果您想保护存储的浏览器历史记录、某些类型的日志记录以及查看您的 URL 的人，那么 POST 更安全。
如果您想防止有人嗅探您的网络活动，那么没有区别。
免责声明：以下几点仅适用于 API 调用，不适用于网站 URL。
网络安全：您必须使用 HTTPS。在这种情况下，GET 和 POST 同样安全。
浏览器历史记录：对于前端应用程序，如 Angular JS、React JS 等 API 调用是前端进行的 AJAX 调用。这些不会成为浏览器历史记录的一部分。因此，POST 和 GET 同样安全。
服务器端日志：通过使用数据屏蔽和访问日志格式的写入集，可以隐藏请求 URL 中的所有或仅敏感数据。
浏览器控制台中的数据可见性：对于有恶意的人来说，查看 POST 数据和查看 GET 数据几乎相同。
因此，通过正确的日志记录实践，GET API 与 POST API 一样安全。随处跟随 POST 会强制 API 定义不佳，应避免使用。
许多人采用一种约定（Ross 提到），GET 请求只检索数据，不修改服务器上的任何数据，而 POST 请求用于所有数据修改。虽然其中一个本身并不比另一个更安全，但如果您确实遵循此约定，则可以应用横切安全逻辑（例如，只有拥有帐户的人才能修改数据，因此拒绝未经身份验证的 POST）。
我不打算重复所有其他答案，但有一个方面我还没有看到 - 它是数据消失的故事。我不知道在哪里可以找到它，但是...
基本上它是关于一个网络应用程序，每隔几个晚上就会神秘地丢失所有数据，没有人知道为什么。检查日志后发现该网站是由谷歌或其他任意蜘蛛发现的，它很高兴地获取（阅读：GOT）它在网站上找到的所有链接 - 包括“删除此条目”和“你确定吗？” 链接。
实际上-已经提到了其中的一部分。这就是“不要在 GET 上更改数据，而只能在 POST 上更改数据”背后的故事。爬虫会很高兴地遵循 GET，而不是 POST。即使是 robots.txt 也无助于防止行为不端的爬虫。
您还应该注意，如果您的网站包含指向您无法使用 GET 控制的其他外部网站的链接，则当他们按下您网站上的链接时，会将这些数据放在外部网站的引用标题中。因此，通过 GET 方法传输登录数据始终是一个大问题。因为这可能会暴露登录凭据，以便通过检查日志或查看 Google 分析（或类似内容）轻松访问。
RFC7231：
" URI 旨在共享，而不是安全的，即使它们标识了安全资源。URI 通常显示在显示器上，在打印页面时添加到模板中，并存储在各种不受保护的书签列表中。因此，包含URI 中敏感的、可识别个人身份的或有披露风险的信息。
服务的作者应该避免使用基于 GET 的表单来提交敏感数据，因为这些数据将被放置在请求目标中。许多现有的服务器、代理和用户代理在第三方可能看到的地方记录或显示请求目标。此类服务应该改用基于 POST 的表单提交。”
该 RFC 明确指出不应使用 GET 提交敏感数据。由于这句话，一些实现者可能不会以同样的谨慎处理从 GET 请求的查询部分获得的数据。我自己正在制定一个协议，以确保数据的完整性。根据这个规范，我不应该保证 GET 数据的完整性（我会这样做，因为没有人遵守这些规范）
正如之前有人所说，HTTPS 带来了安全性。
但是，POST 比 GET 更安全一点，因为 GET 可以存储在历史记录中。
但更可悲的是，有时 POST 或 GET 的选择并不取决于开发人员。例如，超链接始终通过 GET 发送（除非使用 javascript 将其转换为发布表单）。
GET 对任何人都是可见的（甚至是你现在肩上的那个）并且保存在缓存中，因此使用 post 的安全性较低，顺便说一句，没有一些加密例程的 post 不确定，为了一点安全性，你必须使用 SSL（ https)
不同之处在于 GET 发送数据打开和 POST 隐藏（在 http-header 中）。
因此 get 更适合非安全数据，例如 Google 中的查询字符串。永远不能通过 GET 发送 Auth-data - 所以在这里使用 POST。当然，整个主题要复杂一些。如果您想了解更多信息，请阅读这篇文章（德语）。
POST 的安全性较差的一个原因是 GET默认记录，参数和所有数据几乎普遍由您的网络服务器记录。
POST则相反，它几乎普遍没有记录，导致很难发现攻击者活动。
我不赞成“它太大”的论点，这没有理由不记录任何东西，至少 1KB，对于人们识别攻击者在一个弱入口点工作直到它弹出，然后 POST 确实有很大帮助通过启用任何基于 HTTP 的后门来静默传递无限量的数据，这是一种双重破坏。
最近发布了一个攻击，它允许中间人泄露压缩的 HTTPS 请求的请求正文。因为请求标头和 URL 没有被 HTTP 压缩，所以 GET 请求可以更好地抵御这种特定的攻击。
在某些模式下GET 请求也容易受到攻击，SPDY 压缩请求标头，TLS 还提供可选（很少使用）压缩。在这些情况下，攻击更容易预防（浏览器供应商已经提供了修复）。HTTP 级别压缩是一个更基本的功能，供应商不太可能禁用它。
这只是一个示例，显示了 GET 比 POST 更安全的场景，但我认为从这种攻击原因选择 GET 而不是 POST 不是一个好主意。攻击非常复杂，需要非平凡的先决条件（攻击者需要能够控制部分请求内容）。在攻击可能有害的情况下，最好禁用 HTTP 压缩。
除非使用 https，否则没有安全性 - 使用 https，GET 和 POST 之间的传输安全性相同。
但是一个重要的方面是客户端和服务器在记住请求时的区别。在考虑使用 GET 或 POST 登录时，记住这一点非常重要。
使用 POST，密码由服务器应用程序处理然后丢弃，因为一个好的设计不会在数据库中存储密码 - 只有加密安全的哈希值。
但是使用 GET，服务器日志最终会包含带有查询参数的请求。因此，无论数据库中的密码哈希有多好，服务器日志仍将包含明文密码。除非文件系统被加密，否则即使在日志文件被删除后，服务器磁盘也会包含这些密码。
The same problem happens when using access tokens as query parameters. And this is also a reason why it is meaningful to consider supplying any access token in the HTTP header data - such as by using a bearer token in the Authorization header.
The server logs are often the weakest part of a web service, allowing an attacker to elevate their access rights from leaked information.
这是一篇旧帖子，但我想反对一些答案。如果您要传输敏感数据，则需要使用 SSL。如果您使用带有 GET 参数的 SSL（例如 ?userid=123），该数据将以纯文本形式发送！如果您使用 POST 发送，这些值会被放入消息的加密正文中，因此对于大多数 MITM 攻击来说是不可读的。
最大的区别是数据的传递位置。只有在将数据放在 URL 中时才有意义，它不能被加密，否则您将无法路由到服务器，因为只有您可以读取 URL。这就是 GET 的工作方式。
简而言之，您可以通过 SSL 在 POST 中安全地传输数据，但无论是否使用 SSL，您都无法使用 GET 来做到这一点。
甚至 POST 也接受 GET 请求。假设您有一个包含 user.name 和 user.passwd 等输入的表单，它们应该支持用户名和密码。如果我们简单地添加一个?user.name="my user&user.passwd="my password"，那么请求将被“绕过登录页面”接受。
一个解决方案是在服务器端实现过滤器（java 过滤器作为 e）并检测没有字符串查询作为 GET 参数传递。
Post 与 SSL 一起安装是最安全的，因为它在消息正文中传输。
但是所有这些方法都是不安全的，因为它在其下面使用的 7 位协议可以通过擒纵装置破解。即使通过 4 级 Web 应用程序防火墙。
套接字也不能保证......即使它在某些方面更安全。