A Google Search on this topic just returns results explaining how to hack Google Analytics site search for POST-based search engine measurement. So, I thought I would turn to you fine men and women for help.

I know the main differences between GET and POST involve security and caching (POST requests are secure and are not cached). So, for some applications it makes perfect sense to use POST rather than GET.

However, I'm working with an internal site search engine that receives and returns SERP requests POST-style. Why would it be designed to do that? What are the benefits? I can't imagine it's important to keep search queries secure. Maybe it has something to do with not caching those queries?

All I see is a complication for Web Analytics, so I'm really looking for some enlightenment.

Thanks so much in advance to anyone who can help me understand this.

  • 2
    I'm concerned by your statement that POST requests are "secure". I assume you're talking about URL parameters. A POST over HTTP (no s) isn't much better than a GET over HTTP; anyone can look at the data in the body of the request. On the flip side URL parameters are encrypted in a GET request over HTTPS.
    – Doval
    Jul 6, 2016 at 12:24
  • 1
    Are there a lot of parameters passed? A GET can only pass parameters in a query string, which is of limited length (to various degrees in different browsers). A POST will allow the data to be in the body and be much larger (perhaps unlimited, I forget). Jul 6, 2016 at 15:36

2 Answers 2


So, when a GET request is sent over HTTPS, its query parameters are secure in transit. However, it can more easily leak data at the endpoints (browser history, referrer URLs, and server logs notably) than POST can. See this answer and this old blog post.

Aside from referrer leakage, I'm usually not too concerned about using GETs. GET URLs are nice precisely because you can bookmark and share queries that you commonly run. Often, if I'm deciding between POST and GET for queries, it more comes down to these factors:

Can the search parameters fit in a URL query string?

Some browsers will truncate URLs past a certain size.

If you have a complex object representing your request, then it can be difficult to convert to/from a URL query string automatically.

Is my request object useful as part the URL?

Even if you can convert/fit an object into a query string representation, that doesn't mean it will be useful to do so. If you have too many properties, it is still tedious to construct query strings in the browser.

In contrast, using POST you can include your complex or large request object as JSON or whatever format you fancy. If you want to log it, you still can through your application.

I often use GETs for full text type searches:

GET /customer?skip=0&take=50&search=my+search+text

But for more complex scenarios, I might use POST based on the guiding factors above.

If you look at most search engines, they use GET with query parameters. It's the best fit for what they do. For the analytics services POST-based makes sense, because it offers a lot more fine-grained control over your requests via more complex request objects.


It's not that searches would be malicious; any input into any system, "COULD" be malicious. We have to think that way. And, yes, GET is less secure than POST. GET can leave out steps that help to secure resources.

First, try to think of search as just an input at the attack surface. In this case port 80 or 443 e.g. are listening for HTTP method requests. In this case, search is a POST. The POST may require authentication. It may require authorization of some sort. But, for the POST, the input data expected to run the search, is specified but POST format required. This protects the search more than GET because the POST is generally formatted because it's put together by the web page with the submit button.

Malicious users can still draft an HTTP POST operation of malicious origin, but the server is not going to send anything unless the application has implemented a post operation of the particular format. Also, Cross-site scripting exploits are much more difficult using POST.

Again, it's not a "search" function, it's a vulnerable server "input" function with the namespace "search".

  • Thanks so much for your guidance, David. Framing the search function as a vulnerable server input function is really interesting. So, theoretically, someone could write something malicious and use an unsecured search field as a point of entry? Are there any benefits on the implementation side of things? Maybe it's easier to implement a POST-based search engine across multiple clients (if you're the vendor providing the functionality)? Jul 6, 2016 at 13:15
  • Yes. It's a system input on an attack surface. This is how an IT security professional would look at the functionality. Years ago, I was put off by everyone that perceived my code as a threat. It really is. Nothing is truly secure. Most serious intrusions happen when malicious users have proper credentials. These credentials are just not theirs. Authentication for systems is identity management. And every computer-using-individual has a responsibility to maintain his identity with the utmost care. Jul 6, 2016 at 13:21
  • Ryan, I missed part of your question. If your hosting applications are API-based, you can document the POST operation. If your applications are just web applications then users will use your form to POST. There are also ways to hide the HTML source. I would recommend that in almost all cases with web applications. With API REST hosting e.g. you just document the POST and you sleep at night knowing that's the only way into the server via the HTTP POST. This is also a complicated and wide topic too. I hope that I answered your questions. Jul 6, 2016 at 13:51
  • 2
    In what way is POST more secure than GET? The main difference is that a GET is supposed to be idempotent, whereas a POST may have side effects. Whether a GET leaves out security relevant steps is solely down to the configuration of your web server. Jul 6, 2016 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.