By default, no. Log request metadata such as method, path, status, size, duration and user ID, and leave the body out. Bodies routinely carry passwords, tokens and personal data, and a log store is usually readable by far more people than the database. Capture bodies only narrowly, briefly and with redaction.
Why bodies are risky
The OWASP Logging Cheat Sheet lists data that should not be logged directly: session identifiers, access tokens, authentication passwords, database connection strings, encryption keys and payment card data. It also names sensitive personal data and commercially sensitive information. Instead, the data should be removed, masked, sanitised, hashed or encrypted. And it says never log data unless it is legally sanctioned.
A request body is where those items live. A login form posts a password. An API call carries a token or a customer record. If you log the whole body, you copy secrets into a second system with weaker controls and often longer retention.
OWASP Top 10 A09 names a related weakness, CWE-532, insertion of sensitive information into a log file.
What to log instead
| Log this | Skip this |
|---|---|
| Method, route template, status code | Full body |
| Body size and content type | Authorization and Cookie headers |
| Duration | Query strings that hold tokens |
| User and tenant IDs | Form fields such as password |
| Request ID | Uploaded file contents |
| Validation outcome, field names that failed | The values that failed |
Use the route template, such as a path with an ID placeholder, rather than the raw URL. It groups traffic sensibly and avoids IDs or tokens leaking into paths.
Logging which field failed validation, but not the value, still tells you what an attacker is probing. The OWASP sheet says input validation failures should be treated as suspicious, not as proof of attack.
When you really need bodies
Debugging an integration sometimes needs the payload. Do it in a controlled way:
- Enable body logging for one route, one tenant or one request ID, not globally.
- Run an allow list of fields to keep, and mask everything else. An allow list is safer than a deny list.
- Set a short expiry and a switch that turns it off by itself.
- Restrict who can read that stream and record access to it, as the OWASP sheet asks.
- Never enable it on authentication, payment or health data routes.
Check what you already log
Search your log store for strings that should not be there: the word password, Bearer, long random looking tokens, email addresses. If a search finds them, fix the code and rotate any exposed secret, since log retention means the secret may have been readable for weeks.
Consider adding a test in CI that posts a known fake secret through the app and fails if the fake value appears in captured log output.
For related reading see sensitive data exposure in application logs.
Quick check
Can I log bodies if I redact the password field?
Redacting known fields helps, but unknown fields still leak. Prefer an allow list of fields you have chosen to keep.
What about response bodies?
The same risk applies. Responses often contain personal data and tokens, so log size and status instead.
Safeguard's SBOM and dependency scanning covers the libraries behind your logging and web stack. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
