Introduction
Hi Readers! After a go through my previous articles, now we’ll discuss on
difference between HTTP GET and HTTP POST method for the purpose of read-only
or query-based operations in REST APIs.
Hope you must know about long-standing restriction on the utilization of GET
requests for utilization in local apps. This case was found before general use
of REST APIs and traditional web apps (server-side produced HTML). The only
issue was no one truly knew or kept in memory why it wasn’t permitted – as it
was “insecure”.
Let’s have discussion on Get vs. Post.
API Design
First, we must know the reason of using a GET request in a particular RESTful
API. The entire point of an is to is to be capable for exchanging information
through the native protocol of the WWW as it was meant to be utilized — HTTP
v1.1 or HTTP v2for our objective.
This architectural approach is applied in the ‘Roy Fielding PhD dissertation’
in the year 2000. That dissertation does not discuss particularly while one
HTTP approach or another should be utilized. Nor, does it particularly
describe CRUD operations. However, the details of time of utilization of method
over another are remained to the HTTP spec, “the WWW language.”
Hence, REST API design needs to attract inspiration from various sources and
least pragmatism — and skip the religion. This includes the subset of current
HTTP operations that apply traditional CRUD abilities (Create, Read, Edit,
Delete); this is basically POST, PUT, GET, and DELETE. Though, it need not
have to be this approach. Maybe we substitute PUT by PATCH. Probably, DELETE
isn’t utilized and is basically an extra update that PUT/PATCH could focus
on.
If I followed all the pseudo-rules I’ve listened over the years about which
can and cannot be utilized as portion of REST APIs, there would be few HTTP
1.1 spec remained that could truly be utilized — which is type of silly. Some
developers state that a true REST API can only utilize a 201-return code for
POST calls.
Relative security factor of HTTP POST vs. GET
I’ve been in some organizations that have applied a global, heavy-handed,
restriction of the utilization of GET requests for API-type link or even
traditional web app. The reasons cited are basically something along the lines
of:
The data will be viewed in the address bar of a web browser and noted in the
history of web browser.
GET is not more secure than POST while transformed over the wire.
The URL along with query parameters are logged on the server.
If HTTPS (TLS v1.2 or advanced) is being utilized, neither GET nor POST
request parameters can be viewed over the wire. On the other hand, an HTTP
access log doesn’t need to store information on query parameters or, if you
desired to be truly fancy, don’t allow sensitive values.
Afterall, these points will be valid, but lesser intrusive solutions can be
applied to resolve potential issues. Applying powerful policies like
restricting the utilization of GET requests in apps without conducting a
completed threat assessment quantities to security theater (which refers, it
may not help very much from a security posture).
Often these queries center around PII, HIPAA, or same type specifications.
Basically, placing this type of information directly into the query
parameter should be avoided. Some kind of abstraction should be applied to the
design that could be utilized to reference based information indirectly—
considering some procedures like tokenization for PCI information.
Generally, it is strongly suggested to perform within the thought of what
these approaches are supposed to indicate. There is some gray area and space
for dogma/religion to enter into it — recommended to avoid the same.
Accordingly, CRUD method explained above + OPTIONS approach (CORS) is the
formula that has been utilized in almost each REST API I’ve design. The errors
to that were found by minor compromises with users that have fallen into the
critical traps explained in this blog post.
Side Effects of HTTP GET & POST
GET requests need to be utilized to obtain information while designing REST
APIs; POST requests need to be utilized to create information while designing
REST APIs. Making something is considered to be a side effect — if not that
point.
The HTTP GET approach is not to possess side effects. It can be read-only for
obtaining information. It is basically considered a wrong practice to apply
any kind of write utility (the things that will possess side effects) in an
HTTP GET. Although, there isn’t truly anything restricting a developer from
performing this.
The suggestion here is to skip unintended behavior by making some kind of
“write” functionality in a specific GET request. Save the same for the HTTP
POST operations. This is a sequence where utilizing POST is suggested from the
very description of the spec over GET. This is applicable to both traditional
web apps and REST APIs.
HTTP Logging on Servers
If your app is logging sensitive values any way, just STOP IT now! This
contains the general HTTP access log which most of the web server technologies
have empowered. This is not good practice and one that common auditing and
application to ideal practices should be capable to mitigate.
No need to disable all production logging. The shops can either disable all
production logging of web servers and app servers completely or can disable
the HTTP access log. This might be impossible to conduct forensic analysis or
after-error trouble shooting organized on a system that has possessed all apps
and disabled middleware logging.
The objective must be to filter out to start with the logging of parameters
which are sensitive or might carry sensitive value. As per the product being
utilized, this could either be easier or impossible. I would consider the
capacities required here to be part of the technical need for any type of
products though, most organizations aren’t considering that holistically while
selecting products.
HTTP Referer:
HTTP requests produced by a web browser will generally include a request
header named Referer. This contains the URL of the web page that produced it.
If sensitive data is being carried through a request request URL, probably, the
same URL could finish up in upcoming request Referer headers. A POST request
won’t have this issue.
Nevertheless, for the AJAX, REST API calls from a web browser, the Referer header will have the JavaScript file’s URL that began the
request. This
isn’t becoming specially interesting. For a system-to-system API call, the
most likely won’t even be a Referer header. So, in most API-related cases,
this isn’t becoming an issue.
Proxy Caching of HTTP GET requests
The comments raised in the last section regarding which organization owns the
proxy are narrated here. If a proxy cannot be classified as trusted, steps
need to be taken to skip it.
Where we have viewed reply caching was on something like a CDN in the front
side of API Gateway or developed into an API Gateway. Turning this
characteristic on, was generally accomplished with particular intent that has
made sense for the API replies being captured. When utilized, it adheres to
the HTTP directives referring how long something needs to be captured and
whether it needs to be captured.
There is also the difference of caching according to HTTP Header, complete
path, query parameters, etc. This can be changed widely.
In theory, you could get the reply of any HTTP approach, but rarely this makes
reason for writing operations. If it was mandatory to cache something, tending
to apply capturing of API requests (read-only) which covered in POSTs might be
challenging (it could be accomplished with certainly completely characterized
products, but it would cause nonsensical situations). This would be a specific
reason to utilize GET for read-only API calls except POST.
This section applies to common web apps and REST APIs. For the specific REST
APIs, answer caching doesn’t occur that often, but it happens sometimes.
Showing information in the Web browser
It is true, you can view GET requests with appropriate query parameters in the
address bar and web Browser History. You can also view the whole contents of
POST, PUT, and other HTTP approaches in web browser Developer Tools. One could
often remove the history; though, this generally needs the permission or
cooperation of the end user.
Confused Deputy Attack
According to Wikipedia, a Confused Deputy “is known as a legitimate, highly
privileged computer app which is tricked by other program into utilizing its
authority wrongly on the system. It is a particular kind of privilege
escalation.” However, if the web browser is taken as the deputy in this act,
both GET and POST requests could be included in a ‘confused deputy
attack’.
Cross-Site Scripting Attack
XSS (Cross-Site Scripting) attacks trick a user (or more correctly the user’s
web browser) into displaying an arbitrary script (generally JavaScript). This
generally happens when unfiltered user data (input) is granted to be utilized
in replies sent back to other users like a discussion forum. The unfiltered
input could carry executable JavaScript which conducts an unnecessary action.
This matter is discussed shortly here.
This kind of vulnerability can influence both GETs and POSTs. The mitigation
plans can run across both ‘GET & POST’ requests.
This is a serious concern for genuine web apps and REST APIs, but most likely
is going to need the utilization of a web browser for the API Consumer.
Conclusion
Overall, we have realized from the above that both post and get have equal
importance in various situations. It’s very real that there are some
considered situations where the utilization of a POST request has advantages
of security over a GET request except the extra precautions, but also, in some
situations where both are equally harmful to common attack vectors. It is
critical that best-performances and resolution approaches for common
vulnerabilities could be designed into all web apps. Those small advantages
the POST request have not justified rejecting a GET request from our API
design tool belt.
