我意识到POST不会公开URL上的信息，但是它有任何真正的价值吗？或者仅仅是因为晦涩难懂而已？
编辑：
通过HTTPS，POST数据已被编码，但是URL可能会被第三方监听吗？另外，我正在处理JSP；当使用JSP或类似框架时，可以公平地说最好的做法是避免将敏感数据完全放在POST或GET中，而使用服务器端代码来处理敏感信息吗？
#1 楼
就安全性而言，它们本质上是相同的。的确，POST不会通过URL公开信息，但它在客户机与服务器之间的实际网络通信中公开的信息与GET一样多。如果您需要传递敏感信息，那么第一道防线就是使用安全HTTP传递信息。GET或查询字符串文章对于将特定项目添加为书签或协助搜索引擎优化和索引项目非常有用。
POST适用于提交一次数据的标准表格。我不会使用GET来发布实际的表单，除非您可能希望在搜索表单中允许用户将查询保存在书签中或类似内容中，否则我不会使用GET。
评论
需要注意的是，对于GET，在位置栏中显示的URL可以公开将隐藏在POST中的数据。
– tvanfosson
08-10-13在18:29
只在最幼稚的意义上被隐藏
–davetron5000
08-10-13在18:33
是的，但是您也可以说键盘是不安全的，因为在您输入密码时，有人可能会抬起头来。默默无闻的安全性与根本没有安全性之间几乎没有什么区别。
– stephenbayer
08-10-14在14:59
URL中查询字符串的可见性（和缓存）以及地址框的安全性显然较差。没有绝对的安全性，因此安全程度是相关的。
– pbreitenbach
09年8月19日在5:06
如果使用帖子，它甚至会暴露出来。就您而言，该帖子将更加安全。但是认真的..我可以整天更改post变量，就像获取变量一样容易。 Cookies甚至可以被查看和修改。.永远不要依赖您正在以任何形式发送的信息。您需要的安全性越高，应采用的验证方法就越多。
– stephenbayer
2010-03-21 14:35
#2 楼
GET请求比POST请求的安全性稍差。两者都不提供真正的“安全性”。使用POST请求不会神奇地使您的网站受到恶意攻击的保护，而且数量可观。但是，使用GET请求可能会使原本安全的应用程序变得不安全。您“不得使用GET请求进行更改”的口号仍然非常有效，但这与恶意行为无关。登录表单是使用错误的请求类型发送时最敏感的表单。
搜索蜘蛛和Web加速器
，这是您应该使用POST请求更改数据的真正原因。搜索蜘蛛将跟踪您网站上的每个链接，但不会提交他们找到的随机表格。
Web加速器比搜索蜘蛛差，因为它们在客户端计算机上运行，并在链接器的上下文中“单击”所有链接。登录用户。因此，使用GET请求删除内容的应用程序即使需要管理员，也会很乐意服从（非恶意！）Web加速器的命令并删除其看到的所有内容。
混淆的副手攻击
无论您使用GET还是POST请求，都有可能发生混淆的代理攻击（代理是浏览器）。
在攻击者控制的网站上，无需用户交互，提交GET和POST同样容易。
POST不太容易受到影响的唯一情况是，许多不受攻击者控制的网站（例如，第三方论坛）允许嵌入任意图像（允许攻击者注入任意GET请求），但可以阻止以任何方式注入任意的POST请求，无论是自动还是手动。
有人可能会说Web加速器是混淆的副手攻击的一个例子，但这仅是定义问题。如果有的话，恶意攻击者无法对此进行控制，因此即使代理人感到困惑也几乎不是攻击。
代理日志
代理服务器很可能会完整记录GET URL，而不会剥离查询字符串。 POST请求参数通常不会记录。无论哪种情况，都不太可能记录Cookie。 （示例）
这是支持POST的非常弱的论点。首先，未加密的流量可以完整记录。恶意代理已经拥有了所需的一切。其次，请求参数对于攻击者的使用是有限的：它们真正需要的是cookie，因此，如果它们仅有的是代理日志，则它们不太可能攻击GET或POST URL。 />登录请求有一个例外：它们往往包含用户的密码。将其保存在代理日志中将打开一个攻击媒介，而在POST情况下是不存在的。但是，无论如何，通过纯HTTP登录本质上是不安全的。
代理缓存
缓存代理可能保留GET响应，但不保留POST响应。话虽如此，与将URL转换为POST处理程序相比，可以更轻松地使GET响应不可缓存。
HTTP“ Referer”
如果用户要从页面导航到第三方网站为响应GET请求而提供服务，该第三方网站可以查看所有GET请求参数。
属于“向第三方显示请求参数”类别，其严重性取决于这些参数中的内容。 POST请求自然不受此影响，但是，要利用GET请求，黑客需要在服务器的响应中插入指向自己网站的链接。
浏览器历史记录
，这与“代理日志”非常相似”参数：GET请求连同其参数一起存储在浏览器历史记录中。如果攻击者可以物理访问计算机，则攻击者可以轻松获取这些信息。
浏览器刷新操作
用户点击“刷新”后，浏览器将重试GET请求。关机后恢复选项卡时，可能会这样做。因此，任何操作（例如付款）都将在没有警告的情况下重复进行。
浏览器将在没有警告的情况下重试POST请求。
这是仅使用POST请求更改数据的很好的理由，但是
与恶意行为无关，因此与安全无关。
那我该怎么办？
只使用POST请求来更改数据，主要是出于与安全无关的原因。
如果您的网站执行敏感操作，则您确实需要知道他们在做什么的人，因为这不能一概而论。您需要使用HTTPS，HSTS，CSP，缓解SQL注入，脚本注入（XSS），CSRF和大量特定于您平台的其他功能（例如各种框架中的批量分配漏洞：ASP.NET MVC， Ruby on Rails等）。在“安全”（不可利用）和“不安全”之间没有任何区别。
通过HTTPS，POST数据已编码，但可以URL被第三者嗅探吗？
不，不能被嗅探。但是这些URL将存储在浏览器的历史记录中。
公平地说，最佳实践是避免可能的敏感数据完全放在POST或GET中，并避免使用服务器端代码来处理敏感信息。而是？
取决于它的敏感程度，或更具体地说，以何种方式。显然，客户会看到它。可以物理访问客户端计算机的任何人都可以看到它。客户端可以在将其发送回给您时对其进行欺骗。如果那很重要，请把敏感数据保存在服务器上，不要让它离开。
评论
哎呀，CSRF尽可能与POST一起使用。
–AVID
2010-12-13 12:09
@Lotus Notes，这有点困难，但是您不需要任何类型的XSS。 POST请求一直在各地发送，不要忘记CSRF可以从任何网站获得，不包括XSS。
–AVID
2010-12-15 6:00
不，您不必让其他人可以键入它，这与浏览器将以静默方式获取的GET相反。考虑到每个POST表单都应使用可验证的源哈希进行保护，并且对于GET链接没有这样的手段，这很愚蠢。
–kibitzer
2011年1月17日在20:06
好吧，您可以将散列添加到所有GET请求中，就像将它们添加到POST表单中一样...但是，对于修改数据的任何内容，您仍不应使用GET。
– Eli
2011年1月17日在21:07
在GET上使用POST不会阻止任何CSRF。它只是使他们的操作稍微容易一些，因为它使人们更容易去访问允许包含url图像的随机网站，而不是去您可以控制的网站（足够使用javascript）。进行
#3 楼
与通过HTTP GET发送的变量相比，通过HTTP POST发送的变量没有提供更高的安全性。HTTP / 1.1为我们提供了一整套发送请求的方法：
选项
获取
HEAD
POST
PUT
删除
TRACE
假设您拥有使用GET的以下HTML文档：
<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：
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请求都是：
未加密
两个示例中都包含
可以被窃听，并受到MITM攻击。
易于复制
许多浏览器不支持POST / GET以外的HTTP方法。
许多浏览器的行为会存储页面地址，但这并不意味着您可以忽略其他任何问题。
具体来说：
一个在本质上比另一个更安全吗？我意识到POST不会在URL上公开信息，但是其中有任何真正的价值，还是仅仅是通过隐蔽性实现安全性？这是正确的最佳做法吗？
这是正确的，因为您使用HTTP讲的软件倾向于使用一种方法存储请求变量，而不能仅使用另一种方法阻止某人查看发生在您的浏览器历史记录上，或者来自10岁的认为他们了解h4x0r1ng的其他幼稚攻击，或检查您历史记录存储的脚本。如果您有一个可以检查历史存储的脚本，则可以很容易地检查您的网络流量，因此通过默默无闻的整个安全性只能使脚本小子和嫉妒的女友变得默默无闻。
通过https，可以对POST数据进行编码，但是URL是否可以被第三方监听？
SSL的运作方式如下。还记得我上面发送的那两个请求吗？这是他们在SSL中的样子：
（我将页面更改为https://encrypted.google.com/，因为example.com对SSL没有响应）。
POST结束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/?qyOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4rV/O8ow1pc`?058/8OS_Qy/oSsU'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
sv_%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?/bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r
通过SSL获取
q4312078q
（注意：我将HEX转换为ASCII，其中一些
整个HTTP对话都是加密的，通信的唯一可见部分是在TCP / IP层上（意味着IP地址和连接端口信息）。
所以让我在这里发表一个大胆的声明。您的网站无法通过一种HTTP方法提供比另一种方法更高的安全性，全世界的黑客和新手都确切地知道我该怎么做。如果需要安全性，请使用SSL。浏览器倾向于存储历史记录，RFC2616 9.1.1建议不要使用GET执行操作，而认为POST提供安全性是完全错误的。
是一种安全措施？防止嫉妒者浏览您的浏览器历史记录。而已。
为了进一步证明POST不安全的原因，Facebook到处使用POST请求，那么FireSheep这样的软件如何存在？
请注意，即使您使用HTTPS并且您的站点不包含XSS漏洞，您也可能会受到CSRF的攻击。简而言之，此攻击情形假定受害者（您的站点或服务的用户）已经登录并且具有正确的cookie，然后要求受害者的浏览器对您的（应该是安全的）站点执行操作。如果您没有针对CSRF的保护，攻击者仍可以使用受害者凭证执行操作。攻击者无法看到服务器响应，因为它将被传输到受害人的浏览器中，但损坏通常已在此时完成。
评论
可惜您没有谈论CSRF :-)。有什么联系方式吗？
–弗洛里安人造黄油
2012年5月17日在17:38
@FlorianMargaine在Twitter上添加我，我会给您DM我的电子邮件。 twitter.com/#!/BrianJGraham
–隐身
2012年5月18日在1:21
谁说Facebook是安全的？很好的答案。 +1。
–阿马尔·穆拉利（Amal Murali）
13年11月9日在20:26
“ [...]因此，通过默默无闻的整个安全性只能使脚本小子和嫉妒的女友默默无闻。[...]”。这完全取决于嫉妒的gf的技能。此外，不允许gf / bf访问您的浏览器历史记录。曾经。大声笑。
– turkishweb
16年7月4日在11:55
#4 楼
没有增加的安全性。发布的数据不会显示在历史记录和/或日志文件中，但如果应确保数据的安全性，则需要SSL。
否则，任何人都会嗅探电线仍然可以读取您的数据。
评论
如果您通过SSL获取URL，则第三方将无法看到该URL，因此安全性是相同的
–davetron5000
08-10-13在18:33
GET信息只能在SSL隧道的开始和结尾看到
–雅科
08-10-13在18:35
而当sys管理员通过日志文件进行grep操作时。
– Tomalak
08-10-13在18:36
我要说的是，由于POST数据不会存储在用户的浏览器历史记录中，所以会增加一些安全性，但是GET数据会存储。
–基普
08-10-13在20:16
通过SSL / TLS的HTTP（正确实施）使攻击者嗅探（或主动篡改）该攻击只能看到两件事-目标IP地址和双向数据量。
–亚伦
2011年1月17日在22:06
#5 楼
即使POST与GET相比并没有带来真正的安全优势，对于登录表单或具有相对敏感信息的任何其他表单，请确保您使用POST的方式为：不会显示
POST信息表单中发送的敏感信息（密码等）以后将不会在URL栏中看到（通过使用
GET，它将在历史记录和URL栏中可见）。 。GET还有一个理论上的数据限制。 POST不会。要获取真实的敏感信息，请确保使用
SSL（HTTPS）评论
在默认设置中，每次我在firefox / IE中输入用户名和密码时，它都会询问我是否要保存此信息，特别是这样，以后就不必键入它。
– Kibbee
08-10-13在18:50
Andrew，我认为他的意思是在用户输入字段上自动完成。例如，Firefox会记住我在网站中输入的所有数据，因此，当我开始在搜索框中输入文本时，它将提供使用以前的搜索来完成文本的功能。
–詹姆斯·麦克马洪
08-10-13在18:51
是的，这就是自动完成的重点，不是吗。我的意思是实际的历史记录，而不是自动完成的记录。
–安德鲁·摩尔（Andrew Moore）
08-10-13在20:11
如果攻击者可以访问完整的浏览器历史记录，那么他也可以访问完整的浏览器自动完成数据。
– Mikko Rantalainen
13年5月13日在9:38
#6 楼
GET和POST中的任何一个都不比另一个固有地“更安全”，就像传真和电话中的任何一个都不比另一个更“安全”。提供了各种HTTP方法，因此您可以选择一种最适合您要解决的问题的方法。 GET更适合幂等查询，而POST更适合“动作”查询，但是如果您不了解要维护的应用程序的安全体系结构，则可以轻松地与任何人相处。最好阅读第9章：HTTP / 1.1 RFC的方法定义，以全面了解最初设想的GET和POST的含义。
#7 楼
GET和POST之间的区别不应该从安全性角度考虑，而应从它们对服务器的意图来看。 GET绝不应更改服务器上的数据-至少不更改日志中的数据-POST可以创建新的资源。好的代理不会缓存POST数据，但是它们可以从URL缓存GET数据，因此您可以说POST应该更安全。但是POST数据仍然可以用于性能不佳的代理。
正如许多答案中提到的那样，唯一可以肯定的选择是通过SSL。
但是要做确保GET方法不提交任何更改，例如删除数据库行等。
评论
我同意这一点。问题不是安全性，而是POST和GET的目的。
– pbreitenbach
09年8月19日下午5:16
#8 楼
我通常的选择方法是：获取要通过URL稍后检索的项目。搜索应该是GET，以便稍后可以在要发送的项目上进行search.php？s = XXX
POST
这相对于GET是相对不可见的，很难发送，但是仍然可以通过cURL发送数据。
评论
但是执行POST比获取GET更难。 GET只是地址框中的URL。 POST需要在HTML页面或cURL中使用
#9 楼
这与安全性无关，但是...浏览器不会缓存POST请求。#10 楼
没有人会神奇地赋予请求安全性，但是GET隐含了一些通常会阻止其安全性的副作用。GET URL显示在浏览器历史记录和Web服务器日志中。因此，切勿将它们用于登录表单和信用卡号之类的内容。
但是，仅发布该数据也不能使其安全。为此，您需要SSL。在HTTP上使用GET和POST时，它们都通过有线方式以纯文本形式发送数据。
POST数据也有其他很好的理由-例如，可以提交无限量的数据，或对临时数据隐藏参数用户。
缺点是用户无法为通过POST发送的查询结果添加书签。为此，您需要GET。
#11 楼
考虑这种情况：松散的API接受GET请求，例如：http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1
在某些设置中，当您请求此URL时，如果该请求有错误/警告，这整行记录在日志文件中。更糟糕的是：如果您忘记在生产服务器中禁用错误消息，则此信息仅在浏览器中以纯文本显示！现在您已经将API密钥提供给了所有人。
不幸的是，真正的API是以这种方式工作的。
我不希望拥有一些敏感的想法。日志中的信息或在浏览器中显示它们。 POST和GET不一样。在适当的地方使用它们。
#12 楼
安全性是传输中数据的安全性：POST和GET之间没有区别。
安全性是计算机上数据安全性：POST更安全（没有URL历史记录）
#13 楼
更改POST请求比较困难（比编辑查询字符串需要更多的精力）。编辑：换句话说，这只是出于默默无闻的安全，而几乎没有。评论
我可以使用Firefox的一些附加组件来更改POST请求，就像查询字符串请求一样容易。我什至可以修改cookie数据以适应我的内心需求。
– stephenbayer
08-10-13在18:12
它不会减慢脚本小子的运行速度，而这恰恰是脚本小子一直尝试的事情。问题在于它们有时会成功。
–雅科
08-10-13在18:16
嗯在Firefox中使用附加组件=比查询字符串花费更多的精力。
–失明
08-10-13在18:18
您的回答会使人误以为他们在使用帖子时会更安全，而实际上却并非如此。错误的答案，坏人。
–克里斯·马拉斯蒂·乔治
08-10-13在18:27
我进行了编辑，以使回答的意图更加明确。希望有帮助。
–失明
08-10-13在18:32
#14 楼
除非您定义要保护的安全性，否则安全性概念是没有意义的。如果要保护存储的浏览器历史记录，某些类型的日志记录以及查看您的URL的人的安全性， ，则POST会更安全。
如果您想防止有人嗅探您的网络活动，则没有任何区别。
#15 楼
许多人采用了一个约定（罗斯所禁止的约定），即GET请求仅检索数据，而不修改服务器上的任何数据，而POST请求用于所有数据修改。尽管一种方法在本质上并不比另一种方法更安全，但是如果您遵循此约定，则可以应用跨领域的安全性逻辑（例如，只有拥有帐户的人才能修改数据，因此拒绝未经身份验证的POST）。评论
实际上，它不是HTTP协议的一部分，而是一个“约定”。 RFC对于不同方法的预期非常明确。
–约翰·尼尔森（John Nilsson）
08-10-13在20:01
实际上，如果您允许GET请求修改状态，则可能是浏览器在预装它认为您可能访问过的页面时会意外地执行您不希望其执行的操作。
–杰斯塔
2011年1月18日在9:12
#16 楼
我不会重复所有其他答案，但是有一个我尚未提及的方面-这是数据消失的故事。我不知道在哪里找到它，但是...基本上，它是关于一个Web应用程序的，每隔几天晚上就会神秘地释放所有数据，而没人知道为什么。后来检查日志发现，该网站是由google或其他任意蜘蛛找到的，它很高兴GET（读取：GOT）它在该网站上找到的所有链接-包括“删除此条目”和“您确定吗？”链接。
实际上-已经提到了其中的一部分。这就是“不要在GET上更改数据，而只能在POST上更改数据”背后的故事。抓取者会很乐意遵循GET，而不是POST。甚至robots.txt也无法防止抓取工具行为异常。
#17 楼
您还应该注意，如果您的站点包含指向其他外部站点的链接，则当您按下外部链接时，您将无法使用GET控制将这些数据放在外部站点的refeerer标头中。因此，通过GET方法传输登录数据始终是一个大问题。因为那样可以通过仅检查日志或查看Google Analytics（分析）（或类似数据）来公开登录凭据以便于访问。#18 楼
RFC7231：“ URI旨在共享而不是安全的，即使它们标识了
安全资源。URI也经常显示在显示器上，当页面被添加到
模板中时打印并存储在各种
未受保护的书签列表中，因此将
信息包含在敏感，可识别个人身份的URI中是不明智的。 >
服务的作者应避免使用基于GET的形式提交敏感数据
，因为这些数据将被放置在请求目标中，许多现有的服务器，代理和用户代理log
或将请求目标显示在第三方可见的地方。此类服务应使用基于POST的表单提交
。”
该RFC明确规定，不应使用GET提交敏感数据。因此，某些实现者可能不会同样谨慎地处理从GET请求的查询部分获得的数据。我自己正在研究一种确保数据完整性的协议。根据此规范，我不必保证GET数据的完整性（因为没有人遵守这些规范，所以我会这样做）
#19 楼
就像以前有人说过的那样，HTTPS带来了安全性。但是POST比GET安全一些，因为GET可以存储在历史记录中。
但是，可悲的是，有时POST或GET的选择不取决于开发人员。例如，超链接始终由GET发送（除非使用javascript将其转换为帖子形式）。
#20 楼
GET对任何人都是可见的（甚至现在就在您的肩膀上），并且保存在缓存中，因此不确定使用post的安全性，不确定没有某些加密例程的btw post，出于安全性的考虑，您必须使用SSL（ https）#21 楼
POST的安全性较差的一个原因是，默认情况下记录GET，参数和所有数据几乎都由您的Web服务器记录。POST相反，它几乎都未被记录，导致非常困难发现攻击者的活动。
我不赞成“它太大”的说法，这没有理由不记录任何东西，至少1KB，对于人们识别出攻击力很弱的攻击者大有帮助，点直到弹出，然后POST通过启用任何基于HTTP的后门以静默方式传递无限量的数据来进行双重取消服务。
#22 楼
区别在于GET发送的数据处于打开状态，而POST则处于隐藏状态（位于http标头中）。因此，对于非安全数据（例如Google中的查询字符串），get会更好。身份验证数据绝不能通过GET发送-因此请在此处使用POST。当然，整个主题要复杂一些。如果您想了解更多信息，请阅读这篇文章（德语）。
#23 楼
最近发布了一种攻击，该攻击允许一个中间人泄露被压缩HTTPS请求的请求主体。由于HTTP不会压缩请求标头和URL，因此可以更好地保护GET请求免受这种特殊攻击。在某些模式下，GET请求也容易受到攻击，SPDY压缩请求标头，TLS还提供可选的（很少使用）压缩。在这些情况下，更容易防止攻击（浏览器供应商已提供了修复程序）。 HTTP级别压缩是更基本的功能，供应商不太可能会禁用它。
这只是一个示例，显示了GET比POST更安全的情况，但我认为出于这种攻击原因，最好选择GET over POST。攻击非常复杂，并且要求先决条件（攻击者需要能够控制部分请求内容）。最好在攻击可能有害的情况下禁用HTTP压缩。
#24 楼
免责声明：以下几点仅适用于API调用，不适用于网站URL。网络安全：您必须使用HTTPS。在这种情况下，GET和POST同样安全。
浏览器历史记录：对于诸如Angular JS，React JS等前端应用程序，API调用是由前端进行的AJAX调用。这些不会成为浏览器历史记录的一部分。因此，POST和GET同样安全。
服务器端日志：使用数据屏蔽和访问日志格式的写集，可以从请求URL中隐藏所有或仅敏感数据。 />
浏览器控制台中的数据可见性：对于有恶意的人来说，查看POST数据几乎与GET一样。
因此，采用正确的日志记录做法，GET API是和POST API一样安全。随处进行POST，会导致API定义不正确，应避免使用。
#25 楼
这是一篇旧文章，但我想反对一些答案。如果要传输敏感数据，则需要使用SSL。如果您将SSL与GET参数一起使用（例如？userid = 123），则该数据将以纯文本格式发送！如果使用POST发送，则这些值将放入消息的加密主体中，因此对于大多数MITM攻击来说都是不可读的。最大的区别是数据的传递位置。唯一有意义的是，如果将数据放置在URL中，则不能对其进行加密，否则您将无法路由到服务器，因为只有您才能读取URL。这就是GET的工作方式。
简而言之，您可以通过SSL在POST中安全地传输数据，但是无论是否使用SSL，您都无法通过GET进行数据传输。
评论
这是完全不正确的。 SSL是传输层协议。它首先连接到服务器，然后将所有应用程序数据作为加密的二进制数据流发送。查看以下主题：answer.google.com/answers/threadview/id/758002.html
– Simeon G
2012年2月28日在16:53
做一个TCPDump，您会发现这是100％正确的。为了连接到服务器，您必须发送未加密的请求。如果您以GET的身份进行操作，则您的args将添加到初始请求中，因此不会被加密。无论您在链接的文章中看到什么，都可以使用TCPDump（或类似工具）对其进行测试。
– LVM
2012年8月8日15:31
做完了！只需在Mac上运行tcpdump。而您的答案却是100％错误。这是我使用的命令：sudo tcpdump -w ssl.data -A -i en1 -n dst端口443然后当我查看ssl.data时，我当然看到了gobly gook。所有HTTP数据均已加密。为了确保正常的非ssl调用正常工作，我使用了：sudo tcpdump -w clear.data -A -i en1 -n dst port 80确实，在clear.data内部，所有标头和URI都以明文形式显示。我在gmail和google plus（即HTTPS）以及某些非SSL页面（例如google.com）上对此进行了测试。
– Simeon G
2012-3-11的3:18
我不是网络专家，所以如果您认为我在tcpdump上使用了错误的命令，请随时纠正我。
– Simeon G
2012-3-11的3:21
我没有立即可用的命令，但您也可以使用Wireshark / Ethereal进行检查。
– LVM
2012年3月14日在16:43
#26 楼
甚至POST也接受GET请求。假设您有一个表单，其中包含诸如user.name和user.passwd之类的输入，这些输入应该支持用户名和密码。如果我们仅添加？user.name =“ my user＆user.passwd =” my password“，则请求将通过“绕过登录页面”被接受。对此的解决方案是实现过滤器（在Java端将Java过滤为e），并且检测到没有字符串查询作为GET参数传递。
评论
不对！关于接受POST的代码是否也接受GET，这完全取决于您的后端。
–科林·哈特（Colin't Hart）
2012年10月19日在7:27
#27 楼
Post与SSL一起安装是最安全的，因为它是在消息正文中传输的。但是所有这些方法都是不安全的，因为它下面使用的7位协议可以通过擒纵系统进行黑客攻击。即使通过4级Web应用程序防火墙。
也不能保证套接字...即使在某些方面它更安全。
评论
Jeff的博客《编码恐怖：跨站点请求伪造和您》中有一个不错的博客条目。您不会在大多数情况下使用POST。例如对于API，说您需要从数据库中获取数据，但是在服务器返回数据之前，您必须首先进行身份验证吗？使用post，您只需传递会话ID +请求所需的所有参数。如果为此使用GET req，则可以轻松地在浏览器历史记录或中间位置找到会话ID。
我记得这场讨论是从战前（99或00左右）开始的，当时https并不普遍。
@DavidTonhofer，您指的是哪一场战争？浏览器大战？
@DeltaFlyer不，关于物的永远战争，又名GWOT。我们做了什么。