Monday, November 2, 2009

HTTPS Data Exposure - GET vs POST

Here is a quick chart showing the data exposure when considering GET vs POST and also HTTP vs HTTPS. The secure choice for transmission of any sensitive data is to use POST statements over SSL/TLS. Any other option will expose data at some point in the communication.

  • URL arguments refer to arguments in the URL for GET or POST (e.g.
  • Body arguments refer to data communicated via POST paramaters in the HTTP request body.
This chart does not address client side caching of temporary files. Caching is a separate issue from the protocol selection and should be addressed with appropriate cache-control headers.


  1. Some web servers do support logging POST data, though it may require add-on modules. While enabling it could be space-prohibitive, some orgs may either choose to log a set amount of POST data or only do so for critical applications.

    The chart also does not address logging by a WAF/IDS/etc. between an intermediary point of SSL termination and the web server.

  2. Excellent point about POST logging. An organization that enables such a feature must be aware of the security implications. In addition, I see far to many applications configured to arbitrarily log all headers to a debug file. This means valid sessionIDs are captured and exposed to anyone with access to the log file.

    Regarding WAF/IDS, I would basically lump those into the third category of "Webserver logs". That area was meant to address any devices after the SSL/TLS has terminated.

  3. Nice article. As per my research on this topic, I have seen that we can improve the security concerns regarding GET request by using HTTPS protocol.


Note: Only a member of this blog may post a comment.