Treat logging as behaviour with tests. Trigger a failed login, an access denial and a role change in a test environment, capture the log output, and assert that each event appears with the right name and fields and without secrets. Run these tests in CI so a refactor cannot silently remove an event.
Why test it at all
OWASP Top 10 A09 lists conditions that mark a logging failure, and two stand out for testing: auditable events such as logins and failed logins are not logged, and penetration tests and DAST scans trigger no alerts. Both are discovered late if no one checks.
The OWASP Logging Cheat Sheet says logging should be part of code review and security testing. Its checks include whether events are classified consistently and fields are defined correctly, whether logs resist injection, how the app behaves when logging fails, whether logging can be used to exhaust resources, and whether access controls on log data work.
A test matrix
| Test | Action | Assert |
|---|---|---|
| Failed login logged | Post a wrong password | One authn failure event with account and source, no password |
| Successful login logged | Log in correctly | One success event |
| Denial logged | Request another user's record | One authz failure event with resource ID |
| Role change logged | Change a role as admin | Audit event with old and new values |
| Injection resistance | Send a username with a newline and fake log text | One event, newline escaped or encoded |
| Secret not logged | Send a known fake token in a header and body | Fake value absent from all output |
| Logging failure | Make the log sink unavailable | The request still completes, an error is raised elsewhere |
| Volume | Send a burst of failures | Rate controlled, no disk or memory blow up |
How to build them
- Configure the logger in tests to write to an in memory buffer you can read.
- Write each test as a small request, then search the buffer for the expected event name.
- Check the fields by key, not by matching a whole string, so formatting changes do not break tests.
- Add a negative test for each secret type you handle, using obvious fake values.
- Add one test per audit event that your auditors will ask about.
- Run the suite in your pull request pipeline so missing events block a merge.
Keep the number of tests small and meaningful. A short list that always runs beats a long one people disable.
Test detection too
Logs only help if something reads them. Once a month, run a harmless simulation, such as twenty failed logins across ten test accounts, and check that the alert fires and reaches a person. If a DAST scan against staging triggers nothing, that is the A09 condition in action.
Simulate logging failure
The Cheat Sheet specifically asks for simulated failures such as database loss, disk full and permission errors. The result you want is that the user request still works and an alert says logging is broken. See logging failures must not crash your app.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Where should these tests run?
In the same pipeline as your other tests, on every pull request, so a missing event blocks the merge.
Do I need to test every event?
No. Cover authentication, authorization, privilege changes and any event auditors rely on.
Safeguard's policies and gates run checks on pull requests in the same way. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
