The GET request is marginally less secure than the POST request.
(GET请求的安全性略低于POST请求。)
Neither offers true "security" by itself; (两者都不提供真正的“安全性”。)
using POST requests will not magically make your website secure against malicious attacks by a noticeable amount. (使用POST请求不会神奇地使您的网站安全地受到恶意攻击，数量可观。)
However, using GET requests can make an otherwise secure application insecure. (但是，使用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 malicious behaviour.
(您“不得使用GET请求进行更改”的口号仍然非常有效，但这与恶意行为无关。)
Login forms are the ones most sensitive to being sent using the wrong request type. (登录表单是最敏感使用错误请求类型发送的表单。)
Search spiders and web accelerators (搜索蜘蛛和网络加速器)
This is the real reason you should use POST requests for changing data.
(这是您应该使用POST请求更改数据的真正原因。)
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 .
(Web加速器比搜索蜘蛛差，因为它们在客户端计算机上运行，??并在登录用户的上下文中 “单击”所有链接。)
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 . (因此，使用GET请求删除内容的应用程序即使需要管理员，也会很乐意服从（非恶意！）Web加速器的命令并删除其看到的所有内容 。)
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 submit without 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.
(有人可能会说Web加速器是混淆的副手攻击的一个例子，但这只是定义的问题。)
If anything, a malicious attacker has no control over this, so it's hardly an attack , even if the deputy is confused. (如果有的话，恶意攻击者对此拥有没有控制权，所以这是很难的攻击 ，即使副混乱 。)
Proxy logs (代理日志)
Proxy servers are likely to log GET URLs in their entirety, without stripping the query string.
(代理服务器可能会完整记录GET URL，而不剥离查询字符串。)
POST request parameters are not normally logged. (POST请求参数通常不会记录。)
Cookies are unlikely to be logged in either case. (无论哪种情况，都不太可能记录Cookie。)
(example) (（例）)
This is a very weak argument in favour of POST.
(这是支持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. (其次，请求参数对攻击者的使用是有限的：它们真正需要的是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. (将其保存在代理日志中会打开一个攻击媒介，而在POST情况下是不存在的。)
However, login over plain HTTP is inherently insecure anyway. (但是，无论如何，通过纯HTTP登录本质上是不安全的。)
Proxy cache (代理缓存)
Caching proxies might retain GET responses, but not POST responses.
(缓存代理可能保留GET响应，但不保留POST响应。)
Having said that, GET responses can be made non-cacheable with less effort than converting the URL to a POST handler. (话虽这么说，与将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.
(这与“代理日志”参数非常相似：GET请求连同其参数一起存储在浏览器历史记录中。)
The attacker can easily obtain these if they have physical access to the machine. (如果攻击者可以物理访问计算机，则攻击者可以轻松获取它们。)
Browser refresh action (浏览器刷新动作)
The browser will retry a GET request as soon as the user hits "refresh".
(用户点击“刷新”后，浏览器将重试GET请求。)
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.
(浏览器不会在没有警告的情况下重试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.
(主要出于与安全无关的原因，仅使用POST请求来更改数据。)
- Use only POST requests for login forms;
(仅将POST请求用于登录表单；)
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.). (您需要使用HTTPS，HSTS，CSP，缓解SQL注入， 脚本注入（XSS） ， CSRF以及大量特定于平台的其他功能（例如各种框架中的批量分配漏洞： ASP.NET MVC ， Ruby on Rails等）。)
There is no single thing that will make the difference between "secure" (not exploitable) and "not secure". (没有任何事情可以使“安全”（不可利用）与“不安全”之间产生区别。)
Over HTTPS, POST data is encoded, but could URLs be sniffed by a 3rd party?
(通过HTTPS，可以对POST数据进行编码，但是URL是否可以被第三方监听？)
No, they can't be sniffed.
(不，他们不能被嗅探。)
But the URLs will be stored in the browser history. (但是，URL将存储在浏览器历史记录中。)
Would it be
