An API security log should record who called, what they tried, where it landed, when it happened and what the result was, with a request ID that ties events together. It must never record tokens, passwords, keys, card data or session identifiers in clear form.
Why it matters
You cannot investigate abuse you did not record. OWASP's REST guidance says to write audit logs before and after security events, log token validation errors and sanitise log data to prevent log injection. Its validation advice adds that high volumes of validation failures suggest abuse, which you can only see if failures are logged.
Fields to record
OWASP's Logging Cheat Sheet organises event attributes as when, where, who and what. Applied to an API:
| Group | Fields |
|---|---|
| When | Log time, event time, an interaction or request ID |
| Where | Service name and version, host, method and path (normalised), entry point |
| Who | Source IP, user or client identity, user type if known |
| What | Event type, severity, action attempted, object affected, result, reason, HTTP status code, user agent |
Events worth logging
From the same cheat sheet, the ones that matter most for APIs:
- authentication successes and failures
- authorization failures
- input and output validation failures
- suspicious JWT validation failures
- requests with unexpected HTTP verbs
- administrative actions and use of privileged or shared accounts
- access to sensitive data, and data imports and exports
- attempts to exceed limits and other suspicious business logic activity
Data to keep out
The cheat sheet lists data to remove, mask, hash or encrypt: access tokens and authentication passwords, session identifiers (or a hashed value), database connection strings, encryption keys, payment card data and sensitive personal data. Handle file paths, internal addresses and names with care. Query strings deserve a look, since a token sent there would otherwise be written into every access log.
Practical steps
- Define one log schema for all services, so queries work across them.
- Add a request ID at the edge and pass it downstream.
- Redact in the logging library, not only in review.
- Log authorization failures with the object type, not the object contents.
- Alert on spikes of 401, 403, 429 and validation errors.
- Set retention to match your policy and keep logs access controlled.
Check it works
Run a scan or a test with a fake token in a header and in a query string, then search your logs for that value. If it appears, fix the redaction. Then trigger a few failures and confirm each one is searchable by request ID.
Quick check
Should I log request bodies?
Rarely in full. Log selected non sensitive fields, sizes and identifiers. Full bodies often contain personal data and secrets.
How do I log without breaking privacy rules?
Minimise personal data, pseudonymise where identity is not needed, and set a retention period. Confirm the details with your privacy team.
Safeguard's free scan at gold.safeguard.sh/scan covers dependency risk, including logging libraries.
Sources
Last reviewed: 19 October 2026.
