Fail Securely

From The Secure Arc Wiki

Jump to: navigation, search



Errors and exceptions will be treated in the same way as a denied privilege


Programmatic authorisation checks need to take into account the alternate flows when error conditions occur. The authorisation checks performed in that same block of code need to be consistent through all flows. A simple example is when a default value is provided for an authorisation decision and an error occurs before it is set to its appropriate value. A good example is provided at the OWASP link below.

Further detailed information is available at OWASP.

Related References

Policies & Standards

NIST Special Publication sp-800-42

  • Section 3.12 - General Information Security Principles
    • If a failure occurs, the system should fail in a secure manner. That is, if a failure occurs, security should still be enforced. It is better to lose functionality than lose security.

Saltzer and Schroeder

  • Base access decisions on permission rather than exclusion. This principle, suggested by E. Glaser in 1965, means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. A conservative design must be based on arguments why objects should be accessible, rather than why they should not. In a large system some objects will be inadequately considered, so a default of lack of permission is safer. A design or implementation mistake in a mechanism that gives explicit permission tends to fail by refusing permission, a safe situation, since it will be quickly detected. On the other hand, a design or implementation mistake in a mechanism that explicitly excludes access tends to fail by allowing access, a failure which may go unnoticed in normal use. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation.
    • Ref: Saltzer and Schroeder, The Protection of Information in Computer Systems link.

Design Patterns


Personal tools