9 Handling failures securely

What is it that makes failures so interesting from a security perspective? Could it be that many systems reveal their internal secrets when they fail? Or is it how handling failure defines a system’s level of security? Regardless, recognizing that failures and security go hand-in-hand is incredibly important when designing secure software. This, in turn, requires understanding what the security implications are when making certain design choices. For example, if you choose to use exceptions to signal errors, you need to make sure you don’t leak sensitive data. Or when integrating systems, if you don’t recognize the danger of cascading failures, you could end up with a system as fragile as a house of cards.

9.1 Using exceptions to deal with failure

9.1.1 Throwing exceptions

9.1.2 Handling exceptions

9.1.3 Dealing with exception payload

9.2 Handling failures without exceptions

9.2.1 Failures aren’t exceptional

9.2.2 Designing for failures

9.3 Designing for availability

9.3.1 Resilience

9.3.2 Responsiveness

9.3.3 Circuit breakers and timeouts

Always specify a timeout

9.3.4 Bulkheads

9.4 Handling bad data

Cross-site scripting and second-order attacks

9.4.1 Don’t repair data before validation

9.4.2 Never echo input verbatim

Summary