5 things to keep out of your application logs

A useful log explains what happened without becoming a second store of credentials and customer data. That distinction gets lost when a convenient debug statement turns an entire request into a permanent record.

OWASP's Logging Cheat Sheet identifies data that should usually not be recorded directly, including passwords, access tokens, session identifiers, database connection strings and sensitive personal information. It also recommends recording useful security events. The answer is not to switch logging off.

These five checks are a starting point for reviewing what your application emits. They are not a complete compliance checklist or a promise that a redaction library catches everything.

1. Passwords and other primary secrets

A failed login is worth recording. The password that failed is not.

Keep the event type, time, outcome and an appropriate account or interaction identifier. Do not serialize the submitted login form just because authentication threw an exception. The same review should cover password-reset inputs, encryption keys and other primary secrets.

My suggestion is to define the event before choosing its fields. A login_failed event with a reason category is easier to review than a generic error containing whatever object happened to be available.

Also inspect the error path. Removing a password from the normal request logger does not help if an exception handler later dumps the original request. OWASP's Secrets Management Cheat Sheet treats secret handling as a lifecycle problem, not something solved by hiding one field in one place.

2. Access tokens and raw session identifiers

An authorization failure can be useful evidence without including the credential used in the attempt. Review authorization headers, cookies and token-bearing URLs rather than looking only for a JSON field named token.

OWASP lists access tokens and session identification values among data that usually should not be recorded directly. If session-level correlation is necessary, its logging guidance suggests considering a hashed replacement for the session value.

That is not an instruction to hash every secret and keep the result forever. Decide why correlation is needed, how the replacement is generated and who can access it. A stable identifier can still connect activity across records.

For routine debugging, consider an interaction ID created for the request. Use it to connect the safe events in that request rather than copying the user's bearer token into each line. The identifier itself still needs a clear format and purpose.

3. Database connection strings and service credentials

A connection error does not need to print the credential that failed. Connection strings can combine routing details with authentication material, so treating the whole string as harmless configuration is a poor default.

Record the operation, a safe service alias, a classified error and the interaction ID where useful. Keep the actual credential out of the message. Decide separately whether internal hostnames or paths belong in the logging system; OWASP notes that these can also need special treatment.

Do not rely on replacing the password in one familiar URL pattern. A driver, SDK or configuration library may format errors differently. Test the libraries your application uses, including startup failures before your ordinary request middleware is running.

4. Sensitive personal and financial data

A support case might need an internal customer reference. It does not automatically need the customer's health details, government identifier or payment-card data copied into an application log.

OWASP recommends excluding or protecting sensitive personal information and financial data. It also says ordinary personal information, such as names and email addresses, may need special handling. This is not a universal claim that no personal data can ever be logged. Purpose, consent, applicable rules and the logging system's permitted data classification matter.

For each field, ask what investigation it enables and whether a less revealing reference would work. Then define access and retention for the resulting records. Calling a field "debug data" does not settle those decisions.

Use synthetic customer values when testing this boundary. There is no reason to paste a real customer's private record into a test log to find out whether your filter works.

5. Whole request and response bodies

This is the collection mechanism that can undo the other four checks. A blanket body dump can pick up new fields when your API changes, even if nobody edits the logger.

Full payload logging is not necessary for every useful event. My default would be a small, explicit set of fields for each event, with a separate, reviewed process when deeper diagnostics are genuinely required. An allowlist still needs maintenance: a permitted field can become sensitive when its meaning changes.

Redaction is another layer, not proof of safety. Test nested objects, arrays, error messages and unexpected field names. Check the emitted record at the destination, not only the object passed to your logging function.

Keep the event, review the data

Start with one important workflow. Trigger success, validation failure and an exception using clearly synthetic markers. Inspect what reaches each configured destination. Confirm that useful outcomes remain visible and restricted values do not appear.

Then add that check to your release process. Logging changes when code, SDKs and configuration change. The goal is a record you can investigate without first wondering whether the record itself contains another secret to protect.

Cover photo by Daniil Komov, free to use under the Unsplash License.

I write about startups and AI on StartupWiki.