CWE-636, Not Failing Securely ('Failing Open'), is a design weakness. When the product hits an error, its design drops to a state less secure than the alternatives, such as the weakest encryption algorithm or the most permissive access rules. It applies broadly, including ICS/OT systems.
How it happens
MITRE says this typically comes from wanting to "fail functional" to cut administration and support costs, instead of "failing safe." If the authorization service times out, let the request through. If the strong cipher fails to negotiate, use the weak one. Each choice is convenient and each hands the attacker a lever: cause the failure.
# Fails open
try:
allowed = authz.check(user, resource)
except Exception:
allowed = True # service down, let everyone in
# Fails closed
try:
allowed = authz.check(user, resource)
except Exception:
log.error("authz unavailable")
allowed = False
The record's observed examples include a browser where failed connection attempts reset DNS pin restrictions, letting an attacker rebind a domain name and bypass the same origin policy (CVE-2007-5277), and incorrect prioritization that led to a weaker cipher being selected.
What an attacker gains
Intended access restrictions can be bypassed, often in ways the administrator does not expect. At the least, MITRE notes, it gives administrators a false sense of security.
How to find it
The record lists no detection methods. Review error handling in every security decision: authentication, authorization, crypto negotiation, input validation. For each, write down what happens when the check cannot complete, then test it by breaking the dependency.
How to fix it
MITRE's mitigation: subdivide and allocate resources and components so that a failure in one part does not affect the entire product. Alongside that, make deny the default result of any security check that errors, and alert on the failure so an operator sees it.
A closer look at the failure modes
Fail-open designs come in a few recognizable forms. The first is the permissive default, where an error returns true. The second is the downgrade, where a failed negotiation falls back to a weaker algorithm. The third is the reset, where an error clears a protection, as in MITRE's browser example where failed connections reset DNS pinning.
All three share an attacker strategy: induce the error. Sending malformed input, exhausting a dependency or interrupting a connection may be enough. Test for it by turning off each security dependency in a staging environment and observing what the product allows.
There is a real tension here, which MITRE acknowledges by naming the motive: failing functional keeps support costs low. The answer is to be deliberate. For each decision, someone should choose and record whether availability or protection wins on failure, and the default for security checks should be protection.
Segmenting components, as the mitigation suggests, limits the cost of failing closed. If one part denies access when it breaks, the rest of the product keeps running.
Review checklist:
- List each security decision in the product: login, permission check, cipher choice, validation.
- For each, record the result when the check errors or times out.
- Change any permissive result to deny, and log the event.
- Test by disabling each dependency in staging.
Treat any component that your security depends on, including libraries, as part of this list, since a failing parser or crypto routine can trigger the same fallback.
Quick check
What does "fail safe" mean for an access check?
If the check cannot be completed, access is denied, not granted.
