Html GET 或 POST 是否比另一个更安全？

Is either GET or POST more secure than the other?

提问by James McMahon

When comparing an HTTP GET to an HTTP POST, what are the differences from a security perspective? Is one of the choices inherently more secure than the other? If so, why?

将 HTTP GET 与 HTTP POST 进行比较时，从安全角度来看有什么区别？其中一个选择本质上比另一个更安全吗？如果是这样，为什么？

I realize that POST doesn't expose information on the URL, but is there any real value in that or is it just security through obscurity? Is there ever a reason that I should prefer POST when security is a concern?

我意识到 POST 不会公开 URL 上的信息，但这是否有任何真正的价值，或者它只是通过默默无闻的安全性？出于安全考虑，我是否有理由更喜欢 POST？

Edit:
Over HTTPS, POST data is encoded, but could URLs be sniffed by a 3rd party? Additionally, I am dealing with JSP; when using JSP or a similar framework, would it be fair to say the best practice is to avoid placing sensitive data in the POST or GET altogether and using server side code to handle sensitive information instead?

编辑：
通过 HTTPS，POST 数据被编码，但 URL 可以被第 3 方嗅探吗？此外，我正在处理 JSP；当使用 JSP 或类似框架时，是否可以说最佳实践是避免将敏感数据完全放在 POST 或 GET 中并使用服务器端代码来处理敏感信息？

采纳答案by stephenbayer

As far as security, they are inherently the same. While it is true that POST doesn't expose information via the URL, it exposes just as much information as a GET in the actual network communication between the client and server. If you need to pass information that is sensitive, your first line of defense would be to pass it using Secure HTTP.

就安全性而言，它们本质上是相同的。虽然 POST 确实不通过 URL 公开信息，但它在客户端和服务器之间的实际网络通信中公开的信息与 GET 一样多。如果您需要传递敏感信息，您的第一道防线是使用安全 HTTP 传递它。

GET or query string posts are really good for information required for either bookmarking a particular item, or for assisting in search engine optimization and indexing items.

GET 或查询字符串帖子非常适合为特定项目添加书签或协助搜索引擎优化和索引项目所需的信息。

POST is good for standard forms used to submit one time data. I wouldn't use GET for posting actual forms, unless maybe in a search form where you want to allow the user to save the query in a bookmark, or something along those lines.

POST 适用于用于提交一次性数据的标准表单。我不会使用 GET 来发布实际表单，除非可能在搜索表单中您希望允许用户将查询保存在书签中，或者类似的东西。

回答by John Gietzen

The GET request is marginally less secure than the POST request. Neither offers true "security" by itself; using POST requests will notmagically make your website secure against malicious attacks by a noticeable amount. However, using GET requests canmake an otherwise secure application insecure.

GET 请求的安全性略低于 POST 请求。两者都不能单独提供真正的“安全性”；使用 POST 请求不会神奇地使您的网站免受恶意攻击。但是，使用GET请求可以使原本安全的应用程序是不安全的。

The mantra that you "must not use GET requests to make changes" is still very much valid, but this has little to do with maliciousbehaviour. Login forms are the ones most sensitive to being sent using the wrong request type.

“不得使用 GET 请求进行更改”的口头禅仍然非常有效，但这与恶意行为几乎没有关系。登录表单是对使用错误请求类型发送的最敏感的表单。

Search spiders and web accelerators

搜索蜘蛛和网络加速器

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.

这是您应该使用 POST 请求更改数据的真正原因。搜索蜘蛛会跟踪您网站上的每个链接，但不会提交他们找到的随机表单。

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.

Web 加速器比搜索蜘蛛更糟糕，因为它们运行在客户端的机器上，并在登录用户的上下文中“单击”所有链接。因此，使用 GET 请求删除内容的应用程序，即使它需要管理员，也会很乐意服从（非恶意！）网络加速器的命令并删除它看到的所有内容。

Confused deputy attack

迷茫的副攻

A confused deputy attack(where the deputy is the browser) is possible regardless of whether you use a GET or a POST request.

一个困惑副攻击（其中副是浏览器）是不管你是否使用GET或POST请求可能。

On attacker-controlled websites GET and POST are equally easy to submitwithout user interaction.

在攻击者控制的网站上，GET 和 POST同样容易在没有用户交互的情况下提交。

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.

POST 不太容易受到影响的唯一情况是许多不受攻击者控制的网站（例如第三方论坛）允许嵌入任意图像（允许攻击者注入任意 GET 请求），但阻止所有注入任意 POST 请求的方法，无论是自动还是手动。

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 isconfused.

有人可能会争辩说，网络加速器是混淆代理攻击的一个例子，但这只是一个定义问题。如果有的话，恶意攻击者对此拥有没有控制权，所以这是很难的攻击，即使副被混淆。

Proxy logs

代理日志

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)

代理服务器可能会完整记录 GET URL，而不剥离查询字符串。POST 请求参数通常不会被记录。在任何一种情况下都不太可能记录 Cookie。（例子）

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.

这是支持 POST 的一个非常弱的论据。首先，可以完整记录未加密的流量；恶意代理已经拥有它需要的一切。其次，请求参数对攻击者的用途有限：他们真正需要的是 cookie，所以如果他们唯一拥有的是代理日志，他们就不太可能攻击 GET 或 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.

登录请求有一个例外：这些请求往往包含用户的密码。将其保存在代理日志中会打开一个在 POST 情况下不存在的攻击向量。然而，无论如何，通过纯 HTTP 登录本质上是不安全的。

Proxy cache

代理缓存

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.

缓存代理可能会保留 GET 响应，但不会保留 POST 响应。话虽如此，与将 URL 转换为 POST 处理程序相比，GET 响应可以变得不可缓存。

HTTP "Referer"

HTTP“引用”

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.

如果用户要从响应 GET 请求而提供的页面导航到第三方网站，则该第三方网站将看到所有 GET 请求参数。

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.

属于“向第三方显示请求参数”的类别，其严重性取决于这些参数中存在的内容。POST 请求自然不受此影响，但是要利用 GET 请求，黑客需要将指向他们自己网站的链接插入到服务器的响应中。

Browser history

浏览器历史

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.

这与“代理日志”参数非常相似：GET 请求与其参数一起存储在浏览器历史记录中。如果攻击者可以物理访问机器，就可以轻松获得这些信息。

Browser refresh action

浏览器刷新动作

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.

一旦用户点击“刷新”，浏览器将重试 GET 请求。在关机后恢复选项卡时可能会这样做。因此，任何动作（例如付款）都会在没有警告的情况下重复。

The browser will not retry a POST request without a warning.

浏览器不会在没有警告的情况下重试 POST 请求。

This is a good reason to use only POST requests for changing data, but has nothing to do with malicious behaviour and, hence, security.

这是仅使用 POST 请求更改数据的一个很好的理由，但与恶意行为无关，因此与安全无关。

So what should I do?

所以我该怎么做？

• Use only POST requests to change data, mainly for non-security-related reasons.
• Use only POST requests for login forms; doing otherwise introduces attack vectors.
• If your site performs sensitive operations, you really need someone who knows what they're doing, because this can't be covered in a single answer. You need to use HTTPS, HSTS, CSP, mitigate SQL injection, script injection (XSS), CSRF, and a gazillion of other things that may be specific to your platform (like the mass assignment vulnerability in various frameworks: ASP.NET MVC, Ruby on Rails, etc.). There is no single thing that will make the difference between "secure" (not exploitable) and "not secure".

• 仅使用 POST 请求来更改数据，主要是出于非安全相关的原因。
• 仅对登录表单使用 POST 请求；否则会引入攻击向量。
• 如果您的站点执行敏感操作，您真的需要知道他们在做什么的人，因为这不能在一个单一的答案中涵盖。您需要使用 HTTPS、HSTS、CSP、缓解 SQL 注入、脚本注入 (XSS)、CSRF以及可能特定于您的平台的大量其他内容（例如各种框架中的批量分配漏洞：ASP.NET MVC，Ruby on Rails等）。“安全”（不可利用）和“不安全”之间没有任何区别。

---

---

Over HTTPS, POST data is encoded, but could URLs be sniffed by a 3rd party?

通过 HTTPS，POST 数据被编码，但 URL 可以被第 3 方嗅探吗？

No, they can't be sniffed. But the URLs will be stored in the browser history.

不，它们不能被嗅探。但是 URL 将存储在浏览器历史记录中。

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?

公平地说，最佳实践是避免将敏感数据完全放在 POST 或 GET 中，而是使用服务器端代码来处理敏感信息吗？

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.

取决于它的敏感程度，或者更具体地说，取决于它的敏感程度。显然，客户会看到它。任何可以物理访问客户端计算机的人都会看到它。客户端可以在将其发回给您时对其进行欺骗。如果这些很重要，那么是的，请将敏感数据保留在服务器上，不要让它离开。

回答by Incognito

You have no greater security provided because the variables are sent over HTTP POST than you have with variables sent over HTTP GET.

您没有提供更高的安全性，因为变量是通过 HTTP POST 发送的，而不是通过 HTTP GET 发送的变量。

HTTP/1.1 provides us with a bunch of methods to send a request:

HTTP/1.1 为我们提供了一系列发送请求的方法：

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT

• 选项
• 得到
• 头
• 邮政
• 放
• 删除
• 痕迹
• 连接

Lets suppose you have the following HTML document using GET:

假设您有以下使用 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>

What does your browser ask? It asks this:

你的浏览器问什么？它问这个：

 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

Now lets pretend we changed that request method to a POST:

现在让我们假设我们将该请求方法更改为 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

BOTHof these HTTP requests are:

这两个HTTP 请求是：

• Not encrypted
• Included in both examples
• Can be evesdroped on, and subject to MITM attacks.
• Easily reproduced by third party, and script bots.

• 未加密
• 包含在两个示例中
• 可以被窃听，并受到 MITM 攻击。
• 易于由第三方和脚本机器人复制。

Many browsersdo not support HTTP methods other than POST/GET.

许多浏览器不支持 POST/GET 以外的 HTTP 方法。

Many browsersbehaviors store the page address, but this doesn't mean you can ignore any of these other issues.

许多浏览器行为存储页面地址，但这并不意味着您可以忽略任何这些其他问题。

So to be specific:

所以具体来说：

Is one inherently more secure then another? I realize that POST doesn't expose information on the URL but is there any real value in that or is it just security through obscurity? What is the best practice here?

一个本质上比另一个更安全吗？我意识到 POST 不会公开 URL 上的信息，但它是否有任何真正的价值，或者它只是通过默默无闻的安全性？这里的最佳做法是什么？

This is correct, because the software you're using to speak HTTP tends to store the request variables with one method but not another only prevents someone from looking at your browser history or some other naive attack from a 10 year old who thinks they understand h4x0r1ng, or scripts that check your history store. If you have a script that can check your history store, you could just as easily have one that checks your network traffic, so this entire security through obscurity is only providing obscurity to script kiddies and jealous girlfriends.

这是正确的，因为您用来说 HTTP 的软件倾向于使用一种方法存储请求变量，而不是另一种方法只会阻止某人查看您的浏览器历史记录或其他一些自认为了解 h4x0r1ng 的 10 岁孩子的幼稚攻击，或检查您的历史存储的脚本。如果你有一个可以检查你的历史存储的脚本，你也可以很容易地拥有一个检查你的网络流量的脚本，所以通过默默无闻的整个安全只是为脚本小子和嫉妒的女朋友提供了默默无闻。

Over https, POST data is encoded, but could urls be sniffed by a 3rd party?

通过 https，POST 数据被编码，但 url 可以被第 3 方嗅探吗？

Here's how SSL works. Remember those two requests I sent above? Here's what they look like in SSL: (I changed the page to https://encrypted.google.com/as example.com doesn't respond on SSL).

以下是 SSL 的工作原理。还记得我上面发送的那两个请求吗？这是它们在 SSL 中的样子：（我将页面更改为https://encrypted.google.com/因为 example.com 不响应 SSL）。

POST over SSL

通过 SSL POST

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/d4
rV/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

GET over SSL

通过 SSL 获取

##代码##

(note: I converted the HEX to ASCII, some of it should obviously not be displayable)

（注意：我将 HEX 转换为 ASCII，其中一些显然不应该显示）

The entire HTTP conversation is encrypted, the only visible portion of communication is on the TCP/IP layer (meaning the IP address and connection port information).

整个 HTTP 会话都是加密的，唯一可见的通信部分是在 TCP/IP 层（即 IP 地址和连接端口信息）。

So let me make a big bold statement here. Your website is not provided greater security over one HTTP method than it is another, hackers and newbs all over the world know exactly how to do what I've just demonstrated here. If you want security, use SSL. Browsers tend to store history, it's recommended by RFC2616 9.1.1 to NOT use GET to perform an action, but to think that POST provides security is flatly wrong.

所以让我在这里做一个大胆的声明。您的网站并没有通过一种 HTTP 方法提供比另一种更高的安全性，全世界的黑客和新手都确切地知道如何做我刚刚在这里演示的内容。如果您想要安全，请使用 SSL。浏览器倾向于存储历史记录，RFC2616 9.1.1 建议不要使用 GET 来执行操作，但认为 POST 提供安全性是完全错误的。

The only thing that POST is a security measure towards? Protection against your jealous ex flipping through your browser history. That's it. The rest of the world is logged into your account laughing at you.

POST 唯一的安全措施是什么？防止嫉妒的前任翻阅浏览器历史记录。就是这样。世界其他地方都登录到您的帐户，嘲笑您。

To further demonstrate why POST isn't secure, Facebook uses POST requests all over the place, so how can software such as FireSheepexist?

为了进一步说明为什么 POST 不安全，Facebook 到处使用 POST 请求，那么FireSheep 之类的软件怎么会存在呢？

Note that you may be attacked with CSRFeven if you use HTTPS and your site does not contain XSSvulnerabilities. In short, this attack scenario assumes that the victim (the user of your site or service) is already logged in and has a proper cookie and then the victim's browser is requested to do something with your (supposedly secure) site. If you do not have protection against CSRF the attacker can still execute actions with the victims credentials. The attacker cannot see the server response because it will be transferred to the victim's browser but the damage is usually already done at that point.

请注意，即使您使用 HTTPS 并且您的站点不包含XSS漏洞，您也可能会受到CSRF 的攻击。简而言之，这种攻击场景假设受害者（您的站点或服务的用户）已经登录并拥有正确的 cookie，然后请求受害者的浏览器对您的（据称是安全的）站点执行某些操作。如果您没有针对 CSRF 的保护，攻击者仍然可以使用受害者凭据执行操作。攻击者无法看到服务器响应，因为它会被传输到受害者的浏览器，但此时通常已经造成损害。

回答by Jacco

There is no added security.

没有额外的安全性。

Post data does not show up in the history and/or log files but if the data should be kept secure, you need SSL.
Otherwise, anybody sniffing the wire can read your data anyway.

发布数据不会出现在历史和/或日志文件中，但如果数据应该保持安全，则需要 SSL。
否则，任何嗅探线路的人都可以读取您的数据。

回答by Andrew Moore

Even if POSTgives no real security benefit versus GET, for login forms or any other form with relatively sensitive information, make sure you are using POSTas:

即使POST与 相比没有真正的安全优势GET，对于登录表单或任何其他具有相对敏感信息的表单，请确保您使用的POST是：

1. The information POSTed will not be saved in the user's history.
2. The sensitive information (password, etc.) sent in the form will not be visible later on in the URL bar (by using GET, it will be visible in the history and the URL bar).

1. POSTed的信息不会保存在用户的历史记录中。
2. 表单中发送的敏感信息（密码等）稍后在 URL 栏中将不可见（通过使用GET，它将在历史记录和 URL 栏中可见）。

Also, GEThas a theorical limit of data. POSTdoesn't.

此外，GET具有数据的理论限制。POST没有。

For real sensitive info, make sure to use SSL(HTTPS)

对于真实的敏感信息，请务必使用SSL( HTTPS)

回答by Mihai Limb??an

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 idempotentqueries 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.

GET 和 POST 中的任何一个本质上都不比另一个“更安全”，就像传真和电话中的任何一个都不比另一个“更安全”一样。提供了各种 HTTP 方法，以便您可以选择最适合您要解决的问题的方法。GET 更适用于幂等查询，而 POST 更适用于“动作”查询，但如果您不了解您正在维护的应用程序的安全架构，您可以很容易地使用其中任何一个查询。

It's probably best if you read Chapter 9: Method Definitionsof the HTTP/1.1 RFCto get an overall idea of what GET and POST were originally envisioned ot mean.

这也可能是最好的，如果你读第9章：方法的定义中的HTTP / 1.1 RFC得到一个什么样GET和POST最初设想OT平均的总体思路。

回答by ruquay

The difference between GET and POST should not be viewed in terms of security, but rather in their intentions towards the server. GET should never change data on the server - at least other than in logs - but POST can create new resources.

GET 和 POST 之间的区别不应该从安全性的角度来看，而应该从它们对服务器的意图来看。GET 永远不应该更改服务器上的数据 - 至少除了日志之外 - 但 POST 可以创建新资源。

Nice proxies won't cache POST data, but they may cache GET data from the URL, so you could say that POST is supposed to be more secure. But POST data would still be available to proxies that don't play nicely.

好的代理不会缓存 POST 数据，但它们可能会缓存来自 URL 的 GET 数据，因此您可以说 POST 应该更安全。但是 POST 数据仍可用于性能不佳的代理。

As mentioned in many of the answers, the only sure bet is via SSL.

正如许多答案中提到的，唯一确定的赌注是通过 SSL。

But DO make sure that GET methods do not commit any changes, such as deleting database rows, etc.

但是请确保 GET 方法不会提交任何更改，例如删除数据库行等。

回答by edebill

Neither one magically confers security on a request, however GET implies some side effects that generally prevent it from being secure.

没有一个人会神奇地为请求赋予安全性，但是 GET 暗示了一些通常会阻止它安全的副作用。

GET URLs show up in browser history and webserver logs. For this reason, they should never be used for things like login forms and credit card numbers.

GET URL 显示在浏览器历史记录和网络服务器日志中。出于这个原因，它们不应该用于登录表单和信用卡号等内容。

However, just POSTing that data doesn't make it secure, either. For that you want SSL. Both GET and POST send data in plaintext over the wire when used over HTTP.

但是，仅仅发布该数据也不能使其安全。为此，您需要 SSL。当通过 HTTP 使用时，GET 和 POST 都通过网络以明文形式发送数据。

There are other good reasons to POST data, too - like the ability to submit unlimited amounts of data, or hide parameters from casual users.

POST 数据还有其他很好的理由——比如能够提交无限量的数据，或者对临时用户隐藏参数。

The downside is that users can't bookmark the results of a query sent via POST. For that, you need GET.

缺点是用户无法为通过 POST 发送的查询结果添加书签。为此，您需要 GET。

回答by Daniel Silveira

This isn't security related but... browsers doesn't cache POST requests.

这与安全无关，但是……浏览器不会缓存 POST 请求。

回答by Ross

My usual methodology for choosing is something like:

我通常的选择方法是这样的：

• GETfor items that will be retrievedlater by URL
  • E.g. Search should be GET so you can do search.php?s=XXX later on
• POSTfor items that will be sent
  • This is relativelyinvisible comapred to GET and harder to send, but data can still be sent via cURL.

• GET用于稍后将通过 URL 检索的项目
  • 例如 Search 应该是 GET 这样你就可以稍后执行 search.php?s=XXX
• POST将发送的项目
  • 这相对于 GET来说是不可见的，并且更难发送，但仍然可以通过 cURL 发送数据。