2 min read time

Security Fundamentals Part 1: Fail Open vs. Fail Closed

by in Cybersecurity

An understanding of core security fundamentals should not be limited to security teams and penetration testers, but it should also be essential knowledge for developers and application teams.  Whether testing an application for security vulnerabilities or coding functions of a new system, core security concepts should be deep-rooted in one’s mind.  

Many application teams have not been through core security training.  During development of new applications, they often make incorrect assumptions that lead to security vulnerabilities.  This seems to be particularly true of mobile development teams who are often rapidly building apps.  

In this series we will explore several core security concepts and discuss how they relate not just to security teams but also to software development teams.  Part one covers the concept of Fail Open vs. Fail Closed

In application development the concept of Fail Open vs. Fail Closed typically relates to how an application should behave when errors and exceptions are encountered.  When exceptions are thrown, Fail Open systems allow access as opposed to Fail Closed systems that block access

When handling errors, developers need to carefully choose what actions to take.  In deciding whether to fail open or to fail closed, the outcomes of each must be considered.  There are situations where each could be considered more secure than the other.  These cases differ and must be decided on an individual basis. 

Consider a shopping application that sells music.  If a user is purchasing a digital album that will be immediately available for download, what should the application do if an error is encountered while attempting to verify the user’s credit card?  Most likely, the application should fail closed and not allow the user access to the digital download.  The store would likely not want to give the music away until payment is verified.  

In the same application, suppose a user purchases a vinyl album that will be shipped after purchase.  If an error is again encountered during the verification of the user’s credit card, the application may wish to fail open.  In this case, the music store may be able to reattempt the credit card verification before the vinyl album is shipped.  Failing closed in this situation could cost the music store business. 

As illustrated in the music store example, there are situations where it is more appropriate to fail open and situations where it is more appropriate to fail closed.  If these situations are not analyzed, serious logical security flaws could be introduced.  

Often during application development, explicit error handling behaviors are not thought out.  When there is not a detailed fail open or fail closed requirement, error handling behaviors could introduce logical security flaws. 

Developers and application teams need to be trained in core security concepts.  Making incorrect security assumptions could lead to serious vulnerabilities.  Understanding the idea of Fail Open vs. Fail Closed helps ensure secure development. 

Fortify is the market leader, as confirmed by the Gartner Magic Quadrant, that gives customers the choice of on-premise, as-a-service, or a combination of both to assess, assure, and protect applications.  To learn more about Application Security Testing with Fortify, visit www.microfocus.com/appsecurity.


Application security
  • Great tutorial, GregPatton. Your emphasis on the significance of core security fundamentals for each security groups and developers is spot on. It's clean to see a discussion on Fail Open vs. Fail Closed, a notion often left out in the rush of application development.

    I couldn't agree more that the choice between Fail Open and Fail Closed should be carefully considered on a case-by-case basis. Your music store example illustrates this beautifully. It's crucial to balance security with user experience and business needs.

    In my experience, I've located that documenting these choices in a clear and concise manner is essential. Having a well-defined coverage for when to Fail Open and when to Fail Closed no longer completely helps in stopping logical security flaws...but moreover serves as a precious reference for future dev and auditing.

    Additionally, I'd recommend incorporating computerized testing and code overview processes to trap potential vulnerabilities early in the dev cycle. This proactive approach can shop a lot of headaches down the road.

    By the way, I've had the pleasure of working with Andersen in the past, and they have been a treasured associate in making sure our software's security and reliability. 

    It's really impressive, so I'm already on the lookout for a second chat of your story :)