Exploitation
A09
| Security Logging & Alerting Failures
Logging & Alerting Failures (OWASP A09)
Security logging and monitoring failures enable attackers to operate undetected for extended periods. The average time to identify and contain a breach is 241 days (IBM Cost of a Data Breach 2025). Without proper logging, monitoring, and alerting, both active attacks and post-compromise activities go unnoticed.
Information
This category is unique in the OWASP Top 10 — you're testing the absence of security controls
rather than exploiting a vulnerability. The finding is that attacks would not be detected.
What Should Be Logged
Critical Events to Log
- Authentication: Login success/failure, MFA attempts, password resets, account lockouts
- Authorization: Access denied events, privilege escalation attempts
- Input Validation: Injection attempts blocked by WAF or validation
- Data Access: Sensitive data reads, bulk data exports, API key usage
- Admin Actions: User creation/deletion, role changes, configuration changes
- Errors: Application exceptions, 500 errors, unexpected inputs
Testing for Missing Logs
missing-logs-test.sh
# Perform these actions and verify they are logged:
# 1. Failed login attempts (should generate alerts after threshold):
for i in $(seq 1 20); do
curl -s -X POST https://target.com/login \
-d 'username=admin&password=wrong'
done
# Ask the client: were these attempts logged? Was an alert generated?
# 2. Successful login from unusual location/device:
curl -s -X POST https://target.com/login \
-H 'X-Forwarded-For: 185.100.87.1' \
-d 'username=testuser&password=testpass'
# Was the unusual IP flagged?
# 3. Access control violations:
curl -s https://target.com/admin/users \
-H 'Authorization: Bearer REGULAR_USER_TOKEN'
# Was the unauthorized access attempt logged?
# 4. SQL injection attempts:
curl -s 'https://target.com/search?q=1%27%20OR%201=1--'
# Was the injection attempt detected and logged?
# 5. Brute force / credential stuffing:
# Run a low-volume credential test
# Was it detected? How many attempts before detection?Log Quality Assessment
log-quality-check.sh
# If you have access to logs (gray-box/white-box testing):
# Check log format — are essential fields present?
# Good log entry:
# 2024-01-15T10:30:00Z | WARN | auth.login |
# user=admin | ip=192.168.1.100 |
# action=LOGIN_FAILED | reason=invalid_password |
# user_agent=Mozilla/5.0... | session=abc123
# Bad log entry:
# Login failed
# Check for sensitive data IN logs (should NOT be logged):
grep -riE 'password|passwd|secret|token|credit.card|ssn' /var/log/app/
# Passwords and tokens should NEVER appear in logs!
# Check log integrity:
# Are logs sent to a centralized system (SIEM)?
# Can application users modify or delete logs?
# Are logs stored on the same server as the application?
# Check log retention:
# How long are logs kept? (90+ days minimum; PCI DSS requires 12 months)
# Are older logs archived securely?Monitoring & Alerting Assessment
Questions to Ask the Client
- Detection time: How quickly would you detect 20 failed login attempts on one account?
- Alerting: What events trigger automated alerts? Who receives them?
- SIEM: Are logs sent to a centralized SIEM (Splunk, ELK, Sentinel)?
- Incident response: Is there a documented incident response plan?
- Log tampering: Can a compromised server's logs be modified by an attacker?
- Coverage: Are all application tiers logged (web, API, database, infrastructure)?
Testing Checklist
- ☐ 1. Perform failed login attempts and verify they are logged with timestamps and source IPs
- ☐ 2. Perform authorization violations and verify they are logged
- ☐ 3. Trigger application errors and verify error logging
- ☐ 4. Check if injection attempts are detected and logged
- ☐ 5. Verify sensitive data is NOT included in logs
- ☐ 6. Verify logs are sent to a centralized, tamper-resistant system
- ☐ 7. Verify alerting exists for critical events (brute force, admin access)
- ☐ 8. Check log retention period meets compliance requirements
Evidence Collection
Test Actions: List of all security-relevant actions performed during testing
Log Gap Analysis: Which actions were logged vs. which were missing
Sensitive Data in Logs: Examples of passwords/tokens found in log files
CVSS Range: No logging: 5.3–7.5 | Sensitive data in logs: 5.3–6.5 | No alerting on brute force: 6.5–7.5
Remediation
- • Log all security events: Authentication, authorization, data access, admin actions, and errors.
- • Centralize logs: Send all logs to a SIEM for correlation and alerting (ELK, Splunk, Microsoft Sentinel). CloudWatch Logs is a log store, not a SIEM — forward it to a SIEM.
- • Set up alerts: Create alerts for brute force (5+ failed logins), privilege escalation, and data export events.
- • Protect log integrity: Use append-only storage, separate log servers, and tamper detection.
- • Never log secrets: Filter passwords, tokens, credit cards, and PII from all log output.
- • Retain logs: Keep logs for at least 90 days, and 12 months where compliance requires it (PCI DSS: 12 months, with 3 months immediately available).
False Positive Identification
- Logging exists but not monitored: Logs being generated is different from logs being monitored — ask the client about their SIEM/alerting setup before marking logging as adequate.
- Structured logging absence: Missing structured logging format (JSON) is a best-practice gap, not necessarily a vulnerability — focus on whether security-relevant events are captured.
- Log retention policy: Short log retention (30 days) may comply with organizational policy — check regulatory requirements for the client's industry before flagging.