Integrity, Logging and Exceptional Conditions

The defence: log the security-relevant events, protect the logs, monitor and alert on them, and do not log sensitive data. This is the covering-tracks and detection material of Module 1 applied to the application: an application should record what matters, in a form that supports detection and investigation, without itself becoming a disclosure risk. Because most real breaches are detected late or by third parties, improving logging and monitoring shortens the time to detection, which is the whole value.

Mishandling of Exceptional Conditions

The idea. New in the 2025 edition, this category recognises that how an application handles errors, failures and unexpected states is a security matter. An application that handles the normal path correctly but mishandles the exceptional path can be attacked through the exception.

The forms:

• Failing open: when a check fails or a component is unavailable, proceeding as though it succeeded rather than denying. The access-control chapter's "deny by default" is this principle: an authorisation check that fails open grants access. A security control that fails open is worse than none, because it gives false assurance.
• Verbose errors: disclosing internal detail in error messages, the web-server block's finding, seen here as an exceptional-condition failure.
• Inconsistent behaviour on error: error paths that skip validation, release resources incorrectly, or leave the application in an insecure state.
• Unhandled edge cases: inputs or states the design did not anticipate, handled in undefined and possibly unsafe ways, which shades into insecure design.

The defence: handle exceptional conditions safely and deliberately. Fail closed, so a failed check denies rather than grants; return generic errors to users while logging detail server-side; ensure error paths maintain the application's security properties; and design for the exceptional cases, not only the normal ones (the abuse-case thinking of the insecure-design chapter). The principle: the exceptional path deserves the same security attention as the normal path, because attackers deliberately trigger the exceptional path.

Why group these three

They are grouped because each is a category of omission rather than a specific attack: failing to verify integrity, failing to log and watch, failing to handle the exceptional safely. None is a single technique like injection; each is a discipline the application must have. Grouping them keeps the OWASP block complete without giving a full chapter to categories that are largely applications of principles already established (integrity from the CIA and supply-chain material, logging from the detection material, safe failure from access control's deny-by-default). A student should be able to name each, give its idea and one form, and its defence.

A worked example, framed defensively

An assessor reviews an application against these three categories.

• The application accepts updates without verifying signatures. Integrity Failure. Fix: verify update signatures.
• It deserialises data from an untrusted source without integrity checks. Integrity Failure (insecure deserialisation). Fix: do not deserialise untrusted data, or verify integrity and limit reconstruction.
• Access-control failures and login failures are not logged, and no monitoring exists. Logging and Alerting Failure. Fix: log security-relevant events, protect the logs off-host, and monitor.
• An authorisation check fails open when a dependency is unavailable, granting access. Mishandling of Exceptional Conditions. Fix: fail closed.
• Verbose errors disclose internal detail. Mishandling of Exceptional Conditions / Misconfiguration. Fix: generic errors, detail to logs.

The report notes that these are disciplines the application lacks rather than single bugs, and that each maps to a principle already established, which reassures the client that the fixes are well understood. The assessor establishes them by reviewing behaviour and configuration.

What beginners get wrong

• Thinking integrity failures are only about the supply chain. They include unverified updates and insecure deserialisation within the application: trusting code or data whose integrity was not checked.
• Not recognising insecure deserialisation. Reconstructing untrusted serialised data without verification is a specific, dangerous integrity failure that can lead to code execution.
• Treating logging as an operations detail, not a security control. Inadequate logging and monitoring is why breaches go undetected; log the right events, protect and watch them.
• Logging sensitive data. It turns the logs into a target; log what matters without recording passwords, tokens or personal data.
• Ignoring the exceptional path. Attackers trigger errors and edge cases deliberately; a control that fails open, or an error that leaves the app insecure, is exploited. Fail closed.
• Failing open. A security control that proceeds when its check fails gives false assurance and is worse than none.

Quick revision

• Software or Data Integrity Failures: trusting code or data whose integrity is unverified. Forms: unverified updates, insecure deserialisation (reconstructing untrusted serialised data), trusting unchecked data. Fix: verify integrity before trusting (signatures, no deserialising untrusted data).
• Security Logging and Alerting Failures: breaches unseen because events are not logged, or logged and not watched. Forms: not logging security events, no monitoring, tamperable or local-only logs, or logging sensitive data. Fix: log the right events, protect the logs, monitor and alert, do not log secrets (Module 1's detection material at the application).
• Mishandling of Exceptional Conditions (new 2025): errors and edge cases handled unsafely. Forms: failing open, verbose errors, insecure error paths, unhandled edge cases. Fix: fail closed, generic errors with detail logged, secure error paths, design for abuse cases. The exceptional path deserves the same attention as the normal path.
• Grouped as categories of omission, each applying an established principle.

Test yourself

1. What does the Software or Data Integrity Failures category cover, and what is insecure deserialisation?

It covers reliance on code or data whose integrity has not been verified, so that an attacker who can alter it compromises the application, including accepting software updates without verifying they are genuinely from the vendor. Insecure deserialisation is a specific member: taking serialised data from an untrusted source and reconstructing it into an object without verifying its integrity, so that a crafted serialised object can cause dangerous behaviour, in the worst case code execution.

1. Why is inadequate logging and monitoring a Top-10 category rather than an operational detail?

Because it is what allows breaches to go undetected, often for long periods and frequently discovered only by third parties. If an application does not log security-relevant events, an attack leaves no trace to find, and if it logs but nobody monitors, alerts never fire; improving logging and monitoring directly shortens the time to detection, which determines how much damage an attack does, so it is a security control in its own right.

1. What should and should not be logged, and how should logs be protected?

Security-relevant events should be logged: logins and failures, access-control failures, high-value actions and input-validation failures; sensitive data such as passwords, tokens and personal information should not be logged, since that turns the logs into a target. The logs should be protected against tampering and ideally sent off-host to a separate collector, so they remain trustworthy after a compromise, and they should be monitored so that attacks are detected.

1. What does "failing open" mean, and why is it a security failure?

Failing open means that when a check fails or a component is unavailable, the application proceeds as though the check had succeeded rather than denying the action. It is a security failure because a control that grants access when its check cannot be performed gives false assurance and is worse than having no control, so security checks should fail closed, denying by default, which is the deny-by-default principle applied to exceptional conditions.

1. Why are these three categories grouped, and what do they have in common?

They are grouped because each is a category of omission rather than a specific attack technique: failing to verify integrity before trusting code or data, failing to log and monitor so attacks are seen, and failing to handle errors and edge cases safely. Each is a discipline the application must have rather than a single bug, and each applies a principle already established elsewhere in the book, integrity, detection, and deny-by-default, to the application layer.