Handling Exceptional Conditions

Errors are an attack surface

Attackers deliberately trigger unusual conditions: malformed input, timeouts, huge payloads, race conditions and partial failures. Unsafe handling can leak information (stack traces, SQL errors), leave data inconsistent (money debited but order not created), or grant access when a check fails open. Validate input size and type early, set timeouts and resource limits, use transactions for multi-step changes, handle errors centrally with generic responses, and test failure paths, not only the happy path.

Failing closed in an authorisation helper

Python sketch.

def can_access(user, resource):
    try:
        return policy_service.check(user.id, resource.id, timeout=0.5)
    except Exception:
        log.exception("policy check failed", extra={"user": user.id, "resource": resource.id})
        return False      # fail closed: an error never grants access

Limit request sizes

Body size limits, pagination caps and timeouts stop simple denial-of-service attempts and memory exhaustion.

त्वरित जाँच: What does "fail closed" mean?

• When a security check cannot complete, access is denied
• The application shuts down permanently
• Errors are hidden from logs
• Access is granted to avoid downtime