Insufficient logging
About A09:2021 — Security Logging Failures
If you can't see attacks happening, you can't respond to them. The Verizon DBIR consistently finds that the average breach goes undetected for months. Most apps under-log security events because logging isn't visible to users and gets cut when launch dates approach.
Impact: Without logs, you can't tell whether an incident actually happened, what data was accessed, or which accounts were compromised. Insurance providers and SOC 2 auditors will both want evidence of monitoring — its absence is a control failure.
How to fix it: Log every authentication attempt (success and failure), every authorization denial, every privilege change, every payment event. Send logs to an aggregation service (Datadog, Sentry, Logtail) that retains them. Set up alerting on suspicious patterns (e.g. 100 failed logins in 5 minutes).
Common patterns in this category:
- Auth failures logged at debug level (not retained)
- No log aggregation — logs only on the server filesystem
- PII or secrets included in error messages and shipped to log providers
- No alerting on security-relevant events
- Logs without timestamps, user IDs, or request IDs
Compliance coverage
Findings from this rule map to the following framework controls:
See the full compliance coverage page for how XploitScan maps every rule to SOC 2, ISO 27001, and OWASP Top 10 controls.
Scan your code for VC037 and 157 other rules
Free, no signup. Drag and drop a zip or run npx xploitscan scan .