The Error Principle: Why Unhandled Errors Become Security Vulnerabilities

Security code review has a well-established methodology: identify trust boundaries, enumerate attack surfaces, trace data flows, verify permission checks. A reviewer examining a permission check asks: “Does this correctly verify the caller’s authority?” They rarely ask: “What happens if this verification itself fails?”

This asymmetry is the blind spot that the Error Principle addresses.

The Blind Spot

A correct permission check can be rendered completely inert by an exception that is caught and silently swallowed two lines later. The system then behaves as if the check passed. The vulnerability is not in the check — it is in the error handling that converts a failure into a success.

This is Pattern A — the most common error debt pattern found across major platform codebases:

try {
    // Security-critical permission check
    enforcePermission(PERM, pid, uid);
} catch (Exception e) {
    Slog.w(TAG, "Skipping check", e);
}
// Execution continues without enforcement

The catch (Exception e) catches all exceptions — expected and unexpected. The handler logs and continues. Any exception in the permission check produces a silent security success.

Every unhandled error in a security-critical path creates information debt — a measurable gap between the system’s intended security behavior and its actual behavior.

Quantifying the Debt: D_e

The Error Principle introduces a formal metric: D_e = 1 − H_e, where H_e (Handling Entropy) measures the quality of error handling across four factors:

Factor	Weight	What It Measures
Detection quality (α)	0–0.4	Does the catch target the correct exception type?
Handling completeness (β)	0–0.3	Does the handler restore security invariants?
Audit signal (γ)	0–0.2	Is the failure logged for detection/triage?
State preservation (δ)	0–0.1	Is the system left in a safe, consistent state?

A D_e of 0.0–0.2 is minimal debt. A D_e of 0.8–1.0 is maximum debt — treat as a security defect immediately.

Five Recurrent Debt Patterns

Pattern A — Broad exception handlers. catch (Exception e) swallows all exceptions including unexpected ones. Execution continues without enforcement. The most common pattern.

Pattern B — Silent return on failure. A permission check throws, the method returns false or null. Callers treat this as “permission denied” but may handle it as “not needed” — producing a bypass.

Pattern C — TOCTOU. Permission check occurs after the resource has already been consumed or state mutated. The check controls only cosmetic post-processing.

Pattern D — Decorative checks. checkPermission() is called, result stored, but never used for enforcement. Removing the check would produce identical behavior.

Pattern E — Inconsistent state from partial failure. A multi-step operation fails after some steps have committed. Security enforcement steps are skipped; the system continues in an inconsistent state.

Debt Stacking: Why Low-Severity Findings Matter

Individual findings with moderate D_e scores are rarely exploitable in isolation. Their impact emerges through stacking — an attacker moves through multiple services, exploiting each information debt point to shift system state incrementally toward a security bypass.

Each hop in the chain transfers debt from one service to the next. A finding that looks low-severity in isolation becomes the bottleneck in a multi-step bypass chain. This is why the Error Principle scores debt across the entire trust boundary, not just within individual functions.