9 Handling failures securely

 

This chapter covers

  • Separating business and technical exceptions
  • Removing security issues by designing for failure
  • Why availability is an important security goal
  • Designing for resilience for a more secure system
  • Unvalidated data and security vulnerabilities

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

9.3.4 Bulkheads

9.4 Handling bad data

9.4.1 Don’t repair data before validation

9.4.2 Never echo input verbatim

Summary

sitemap