What is Not Failing Securely ('Failing Open') (CWE-636)?

TL;DR: Not Failing Securely (‘Failing Open’) (CWE-636) is a vulnerability where an application’s design requires it to fall back to a less secure state upon encountering an error condition, leading to potential security breaches. Ensure fallback states maintain strong security controls.

What is Not Failing Securely (‘Failing Open’)?

Not Failing Securely (‘Failing Open’) (CWE-636) is a type of security vulnerability that occurs when an application’s design requires it to fall back to a less secure state upon encountering an error condition. As defined by the MITRE Corporation under CWE-636, and classified by the OWASP Foundation under A10:2025 - Mishandling of Exceptional Conditions…

Quick Summary

Not Failing Securely (‘Failing Open’) is a critical vulnerability that can lead to unauthorized access and data breaches. When an application encounters an error condition, it may fall back to a less secure state, such as using weaker encryption or more permissive access controls. This can bypass intended security measures, leading to significant risks.

Jump to: Quick Summary · Not Failing Securely (‘Failing Open’) Overview · How Not Failing Securely (‘Failing Open’) Works · Business Impact of Not Failing Securely (‘Failing Open’) · Not Failing Securely (‘Failing Open’) Attack Scenario · How to Detect Not Failing Securely (‘Failing Open’) · How to Fix Not Failing Securely (‘Failing Open’) · Framework-Specific Fixes for Not Failing Securely (‘Failing Open’) · How to Ask AI to Check Your Code for Not Failing Securely (‘Failing Open’) · Not Failing Securely (‘Failing Open’) Best Practices Checklist · Not Failing Securely (‘Failing Open’) FAQ · Vulnerabilities Related to Not Failing Securely (‘Failing Open’) · References · Scan Your Own Site

Not Failing Securely (‘Failing Open’) Overview

What

Not Failing Securely (‘Failing Open’) occurs when an application’s design requires it to fall back to a less secure state upon encountering an error condition.

Why It Matters

This vulnerability can lead to unauthorized access and data breaches, as intended security measures are bypassed during failure scenarios. Proper fallback states maintain strong security controls even in the event of errors or failures.

Where It Occurs

Applications that do not properly handle exceptional conditions may fail securely by defaulting to less restrictive settings.

Who Is Affected

Developers and administrators who rely on error-handling mechanisms without secure fallbacks are at risk.

Who Is Not Affected

Systems already using robust error handling with secure fallback states are not affected.

How Not Failing Securely (‘Failing Open’) Works

Root Cause

The root cause is the design decision to fall back to a less secure state upon encountering an error condition, rather than maintaining strong security controls.

Attack Flow

1. The application encounters an unexpected error.
2. Instead of handling the error securely, it defaults to weaker encryption or more permissive access controls.
3. This allows unauthorized access and data breaches.

Prerequisites to Exploit

• An application that does not handle errors securely.
• Presence of a failure scenario that triggers insecure fallbacks.

Vulnerable Code

def process_request(request):
    try:
        # Process request
    except Exception as e:
        # Insecure fallback: weaker encryption or more permissive access controls

Secure Code

def process_request(request):
    try:
        # Process request securely
    except Exception as e:
        # Secure fallback: maintain strong security controls, log error and handle gracefully

Business Impact of Not Failing Securely (‘Failing Open’)

Confidentiality

• Sensitive information becomes accessible due to weakened encryption.
• Unauthorized access to confidential data.

Integrity

• Data integrity compromised by unauthorized modifications during failure scenarios.

Availability

• System disruptions caused by insecure fallbacks leading to service outages.

Business Consequences:

1. Financial losses from data breaches and compliance fines.
2. Reputational damage due to security incidents.
3. Legal liabilities for breach of trust with customers.

Not Failing Securely (‘Failing Open’) Attack Scenario

1. The application encounters an unexpected error condition during processing a request.
2. Instead of handling the error securely, it falls back to weaker encryption or more permissive access controls.
3. An attacker exploits this insecure fallback state to gain unauthorized access and modify sensitive data.

How to Detect Not Failing Securely (‘Failing Open’)

Manual Testing

• Check for secure fallback states in error-handling mechanisms.
• Verify that all error conditions lead to a secure state, not weaker security measures.

Automated Scanners (SAST / DAST)

• Static analysis can identify insecure default settings during failure scenarios.
• Dynamic testing can simulate error conditions and verify secure fallbacks.

PenScan Detection

PenScan’s automated scanners such as ZAP, Nuclei, Wapiti, Nikto, SSLyze, Dalfox, and Nmap can detect Not Failing Securely (‘Failing Open’) vulnerabilities.

False Positive Guidance

A false positive occurs when a secure fallback state is incorrectly flagged as insecure due to context not visible to the scanner. Ensure that the code handles errors securely before marking it as vulnerable.

How to Fix Not Failing Securely (‘Failing Open’)

• Design fallback states that maintain strong security controls even in failure scenarios.
• Implement robust error handling mechanisms with secure defaults.
• Verify that all error conditions lead to a secure state, not weaker security measures.

Framework-Specific Fixes for Not Failing Securely (‘Failing Open’)

Java

public void processRequest(HttpServletRequest request) {
    try {
        // Process request securely
    } catch (Exception e) {
        // Secure fallback: maintain strong security controls and log error
    }
}

Node.js

function processRequest(request) {
  try {
    // Process request securely
  } catch (error) {
    // Secure fallback: maintain strong security controls, log error and handle gracefully
  }
}

Python/Django

def process_request(request):
    try:
        # Process request securely
    except Exception as e:
        # Secure fallback: maintain strong security controls, log error and handle gracefully

PHP

function processRequest($request) {
    try {
        // Process request securely
    } catch (Exception $e) {
        // Secure fallback: maintain strong security controls, log error and handle gracefully
    }
}

How to Ask AI to Check Your Code for Not Failing Securely (‘Failing Open’)

Review the following [language] code block for potential CWE-636 Not Failing Securely (‘Failing Open’) vulnerabilities and rewrite it using secure fallback states:

Not Failing Securely (‘Failing Open’) Best Practices Checklist

✅ Design fallback states that maintain strong security controls even in failure scenarios.

✅ Implement robust error handling mechanisms with secure defaults.

✅ Verify that all error conditions lead to a secure state, not weaker security measures.

✅ Test error-handling mechanisms for secure fallbacks during manual testing.

✅ Use automated scanners to identify insecure default settings during failure scenarios.

Not Failing Securely (‘Failing Open’) FAQ

How does Not Failing Securely (‘Failing Open’) work?

When an application encounters a failure, it falls back to a less secure state, such as using weaker encryption or more permissive access controls.

What are the common consequences of Not Failing Securely (‘Failing Open’)?

Intended access restrictions can be bypassed, leading to unauthorized data access and other security breaches.

How does Not Failing Securely (‘Failing Open’) impact confidentiality?

Confidentiality is compromised when sensitive information becomes accessible due to weakened security measures during error conditions.

What are the potential mitigations for Not Failing Securely (‘Failing Open’)?

Subdivide and allocate resources so that a failure in one part does not affect the entire product, ensuring secure fallback states.

How can developers detect Not Failing Securely (‘Failing Open’) vulnerabilities?

Manual testing should include checking error handling mechanisms for secure fallbacks. Automated scanners can also identify insecure defaults during failures.

What are some best practices to prevent Not Failing Securely (‘Failing Open’)?

Ensure that all error conditions lead to a secure state, such as using strong encryption and strict access controls even in failure scenarios.

How does the OWASP Top 10 relate to Not Failing Securely (‘Failing Open’)?

Not Failing Securely (‘Failing Open’) is closely related to A10:2025 - Mishandling of Exceptional Conditions, which emphasizes secure error handling.

Vulnerabilities Related to Not Failing Securely (‘Failing Open’)

References

• MITRE
• OWASP Top 10 - Mishandling of Exceptional Conditions
• NVD.NIST.GOV

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Not Failing Securely (‘Failing Open’) and other risks before an attacker does.