Skip to main content
Web Application Vulnerabilities
CHAPTER 13

Logging, Monitoring, and Error Handling

Updated: May 15, 2026
20 min read

# CHAPTER 13

Logging, Monitoring, and Error Handling

1. Introduction

A bank vault with six-foot steel doors is useless if it has no security cameras or alarms. If thieves spend three weeks drilling through the wall and no one notices, they will eventually succeed. In web application security, Security Logging and Monitoring Failures are so critical that they hold a permanent spot on the OWASP Top 10. In this chapter, we will explore how to build visibility into your application, how to detect active attacks (like brute force attempts), and how to prevent your application's error messages from handing hackers a map of your database.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the difference between operational logging and security logging.
  • Identify what events must be logged (Logins, access control failures).
  • Understand the dangers of Information Disclosure via verbose error messages.
  • Implement secure error handling in production environments.
  • Define the role of centralized monitoring and alerting.

3. Beginner-Friendly Explanation

Imagine a museum security guard.
  • Operational Logging: The guard writes down: "The front door opened at 9:00 AM." (Normal activity).
  • Information Disclosure (The Error): A thief jiggles the lock on a restricted door. A speaker on the door announces: "Error: The lock model is a MasterLock 500, and the internal pin is jammed on cylinder 3." (The door just told the thief exactly how to break it).
  • Security Logging: A thief jiggles the lock. The system silently logs: "Unauthorized access attempt at restricted door by person wearing a red hat."
  • Monitoring & Alerting: The system notices the thief has jiggled 50 different locks in the past 2 minutes. The system automatically triggers a silent alarm, notifying the police.

4. Information Disclosure (Verbose Errors)

When a developer writes code, they want detailed error messages (Stack Traces) to help them debug. The Vulnerability: If a developer leaves debugging mode turned on in production, and a hacker triggers a database error (e.g., via a flawed SQL injection), the server might print: SQL Syntax Error near 'SELECT * FROM users_table WHERE...' in /var/www/html/db.php on line 45 The hacker now knows the exact name of the database table, the internal file path of the server, and the exact query structure. They use this intelligence to craft a perfect attack.

The Defense: In a production environment, users should only ever see a generic message: "An unexpected error occurred. Please try again later." All technical details must be written to a secure internal log file.

5. Security Logging: What to Log

You cannot log every single click, or your hard drives will fill up. You must log actionable security events:
  • Authentication Events: Successful logins, failed logins, password resets, MFA failures.
  • Authorization Failures: A user trying to access an admin page (403 Forbidden).
  • Data Modification: Who deleted an account? Who changed the financial records?
  • Suspicious Input: The WAF blocking a payload containing <script>.

*Crucial Rule:* NEVER log sensitive data. Never log plaintext passwords, session IDs, or credit card numbers. If a hacker breaches the log server, they shouldn't find the keys to the kingdom.

6. Monitoring and Alerting

Logs are useless if nobody reads them. Modern organizations use SIEM (Security Information and Event Management) systems. The web server sends all logs to the SIEM. The SIEM looks for patterns:
  • If a single IP address fails to log in 100 times in 1 minute -> Alert: Brute Force Attack.
  • If an admin account logs in from New York, and 5 minutes later logs in from Russia -> Alert: Impossible Travel (Compromised Account).

7. Mini Project: Create Secure Application Logging

Let's configure a PHP application to securely handle errors and log security events.

Secure Configuration Concept:

php
1234567891011121314151617181920 
// 1. Hide Errors from the User (Production Setting)
ini_set(&#039;display_errors', 0);

// 2. Log Errors to a Secure File on the Server
ini_set(&#039;log_errors', 1);
ini_set(&#039;error_log', '/var/log/secure_php_errors.log');

// 3. Implement a Security Logging Function
function log_security_event($user_id, $event_description, $severity) {
    $timestamp = date("Y-m-d H:i:s");
    $ip_address = $_SERVER[&#039;REMOTE_ADDR'];
    // NEVER log passwords here!
    $log_entry = "[$timestamp] [Severity: $severity] [User: $user_id] [IP: $ip_address] - $event_description\n";
    
    // Write to an isolated security log file
    error_log($log_entry, 3, &#039;/var/log/app_security_events.log');
}

// Example Usage:
// log_security_event('Alice', 'Failed login attempt - Bad Password', 'WARNING');

8. Real-World Scenarios

In 2018, the notification API for the Panera Bread website leaked the personal information of over 37 million customers. The data was exposed in plaintext. The most egregious part of the incident was not the vulnerability itself, but the monitoring failure. A security researcher had warned Panera about the data leak eight months prior. Because the company lacked proper security monitoring and incident response logging, they were completely blind to the fact that their data was openly bleeding onto the internet, allowing the vulnerability to persist unresolved for nearly a year.

9. Best Practices

  • Log Integrity (Append-Only Logs): If a hacker breaches a server, the first thing they do is delete the log files to cover their tracks. To prevent this, logs should be immediately streamed off the web server to an isolated, centralized logging server that is configured as "Append-Only." Even if the web server is compromised, the hacker cannot delete the historical logs stored on the remote server.

10. Legal and Ethical Notes

Compliance frameworks (like GDPR, HIPAA, and PCI-DSS) legally mandate strict logging practices. If a data breach occurs, organizations are required to perform forensics to determine exactly whose data was stolen. If the organization failed to maintain access logs, they cannot prove the scope of the breach, often resulting in maximum regulatory fines for negligence.

11. Exercises

  1. 1. Explain the danger of Information Disclosure via verbose error messages (Stack Traces) in a production environment.
  1. 2. Differentiate between an Operational Log (e.g., Apache Access Logs) and an Application Security Log. What specific events should be captured in a security log?

12. FAQs

Q: Should I log the user's IP address? A: Yes, IP addresses are critical for identifying brute-force attacks and tracing malicious activity. However, under privacy laws like GDPR, IP addresses are considered Personal Data. You must protect the log files and have a data retention policy (e.g., deleting logs after 90 days).

13. Interview Questions

  • Q: Describe the architectural difference between recording logs locally on a web server versus forwarding logs to a centralized SIEM. Why is the latter critical for Incident Response?
  • Q: You are auditing application code and notice that the developer is logging the raw, un-hashed HTTP POST request array whenever a login fails. Identify the severe security vulnerability created by this logging practice.

14. Summary

In Chapter 13, we illuminated the dark corners of the application. We learned that hiding verbose error messages from users prevents critical Information Disclosure, denying attackers the technical maps they need to craft exploits. We defined the necessity of Security Logging, capturing actionable events without capturing sensitive credentials. Finally, we emphasized that logs must be actively monitored by automated systems (SIEMs) to generate real-time alerts, transforming the application from a passive victim into an active defender.

15. Next Chapter Recommendation

We have secured the application code and the monitoring systems. Now, we must travel deeper into the infrastructure to secure the ultimate prize: the data repository itself. Proceed to Chapter 14: Secure Database Practices.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Security Headers and HTTPS Hardening
Next Chapter Secure Database Practices

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5