Why would properly logging full http requests be bad practice?

The key word is properly.

Properly logging HTTP requests when there is a need for it is not bad practice. I am a pen tester and I log all the HTTP requests that I make as part of a test; doing so is expected. I also work on a server system that integrates with a number of complex legacy systems. Logging full HTTP requests on error is a necessary feature. It can show details like which system in a cluster made the erroneous request, which would otherwise be lost.

Veracode is an automated source code analysis system. It can tell if you're passing a HTTP request to a log function. But it cannot really tell if you are logging "properly". So they have come up with this rather vague finding, because that's the best their system can do. Don't put too much weight on it. Does the issue have a risk rating? I suspect it would be low risk. Most people are less thorough than yourself and pay little attention to low risk issues.

They key parts to logging properly are:

• Log injection / forging
• Denial of service
• Confidentiality of logs

You mention the first two in your question. For a personal website, the third one is a non-issue - you're the owner, sys-admin, everything - and only you will have access. This is a much bigger issue in a corporate environment, where you certainly don't want to let everyone in the company have access to the confidential data (like user passwords) in the requests. Some systems deliberately mask parts of data in logs - especially credit card numbers, for PCI compliance.

You mention you extract headers, cookies and parameters and format them in the log file. I recommend you log the raw requests, and have a separate post-processor to format them. There will be odd situations - e.g. parameter duplicated in URL and POST body - that may cause errors. Extracting and formatting can cause the feature in the original request to be lost.

The problem with logging everything is not that you could implement it wrong (eg allow XSS, code execution, buffer overflow, etc), because the solution to that would simply be to do it right, as it is with all code. [You do provide an additional attack surface, but if you decide that keeping additional logs is important, that may well be worth it]

The problem is with what you log: all the headers / cookies and parameters. These obviously may contain sensitive information, such as session ids, login cookies, passwords, credit card information, and so on, in plaintext.

Now, if you only log requests that you know are malicious, it may be ok to log these. But can you be sure of that? Maybe you accidental throw a security exception on a valid action, or you throw one on a security incident that can be produces by a valid user - such as an invalid login because of a typo.

Even if you store these logs securely, you may have vulnerabilities in your code that allow an attacker to read them anyways (eg via LFI). You may also have backups of these logs, which may be compromised. Or an attacker may have gained limited access to the server and gain other useful information from these logs.