I understand that most web servers and web apps do not keep the body of HTTP POST requests in their logs. The reason for this is I assume the potentially large size of the bodies and the possibly sensitive information that they could contain (passwords, credit card numbers...).

But in case a server gets compromised, the POST request bodies could contain valuable data that could help pinpoint the vulnerability that was used to compromise the server.

Are there any best practices for logging POST bodies or is it really just decided on a case by case basis?

3 Answers 3


You can only assess this on a case-by-case basis. As you say, the overheads are pretty large and you may struggle to get such logging to scale sufficiently.

Best to discuss this with whoever manages the web side of things as there may be other logging such as database transaction logs that would provide similar information without adding further overheads.


potentially large size of the bodies

With disk space under 3cents(US)/Gigabyte that's unlikely to be a worry for most people (or $14/day for a saturated T3).

This information is tremendously valuable for support (something which will happen regularly) as well as forensic analysis (something which won't happen very often). Yes, it exposes a big Security risk - but we can neither estimate the level of risk nor the value of the assets which might be exposed. But note that in order to realize the value you need tools to extract the relevant data (and bodies to do the analysis).

There are ways to mitigate the risk - basically don't keep the data on the server - export it to a less exposed server immediately, encrypt it where stored and, if possible filter out authentication tokens first.


You are correct that a high traffic application would soon overwhelm a logging management system if you tried to save all the POST requests. For instance, in a previous role, we were constantly banging up against the limits of our Splunk licenses. Saving all POST requests would have been impossible due to those limits.

The solution is to offload the POST requests into a big data solution such as Hadoop that can take advantage of the low low rates that @symcbean cites.

It sounds like you really want to capture the entire POST request. If this requirement is flexible, consider analyzing what you need from those post requests and only keep that. For example, you might not need every byte of a file upload. To avoid collecting sensitive information, you can configure the logger differently to avoid collecting passwords, sessionIDs and credit card numbers

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .