What is the difference between a HTTP-Get and HTTP-POST and why is HTTP-POST weaker in terms of security
RestRest Problem Overview
Can anyone explain the difference between a HTTP-GET and HTTP-POST? And why do people say that a HTTP-POST is weaker in terms of security?
Rest Solutions
Solution 1 - Rest
In an HTTP GET request, key/value pairs are specified in the URL:
http://server/something?value1=foo&value2=bar</code>;.
In an HTTP POST request, key/value pairs are sent as part of the HTTP request after the headers. For example:
POST /something HTTP/1.1
Host: server
Content-Length: 21
Content-Type: application/x-www-form-urlencoded
value1=foo&value2=bar
It's hard to really describe one as being more or less secure than the other, but HTTP POST data is not visible in the URL, and when submitting data to a website, an HTTP POST can usually only be performed as a result of user interaction (for example clicking on a "Submit" button).
This means a user can't be tricked into visiting a URL like http://server/update_profile?name=I_suck</code> and sensitive data is not exposed in the URL.
You can also use nonces and other anti-forgery tokens with html forms (which use POST) to prevent other forms of cross-site request forgeries.
In general, POST should be used for requests that potentially modify state on the server, and GET should be used for read-only operations.
Solution 2 - Rest
The HTTP specification differentiates POST and GET in terms of their intent:
GET is idempotent: it is for obtaining a resource, without changing anything on the server. As a consequence it should be perfectly safe to resubmit a GET request.
POST is not: it is for updating information on the server. It can therefore not be assumed that it is safe to re-submit the request which is why most browsers ask for confirmation when you hit refresh on a POST request.
In terms of security, no difference. POST is more obscure, perhaps, but that's a very different thing. Security needs to be added at another layer, for example SSL.
Solution 3 - Rest
Some notes on GET requests:
- GET requests can be cached
- GET requests remain in the browser history
- GET requests can be bookmarked
- GET requests should never be used when dealing with sensitive data
- GET requests have length restrictions
- GET requests should be used only to retrieve data
Some notes on POST requests:
- POST requests are never cached
- POST requests do not remain in the browser history
- POST requests cannot be bookmarked
- POST requests have no restrictions on data length
(Source:W3 Schools)
Solution 4 - Rest
I wouldn't call POST more or less secure than GET. Admittedly parameters are displayed as part of the URL when using GET, so any sensitive data will be immediately visible to the user. However, it is trivial to view and even change any part of the HTTP request, so just because POST doesn't pass data through the URL it can still easily be read. Unless you're using HTTPS both GET and POST will transfer data in an easily accessible form.
Solution 5 - Rest
The GET method is meant for data retrieval only and should not have any side-effects. But POST is meant for that specific purpose: altering data on the server side.
GET requests can easily be foreged (see Cross-Site Request Forgery) by just placing an image on a page while forging POST requests is not that easy (this is also a reason why you should only allow authorized POST requests).