# Not Failing Securely ('Failing Open') (CWE-636)

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available.

- Prevalence: Medium 2 languages covered
- Impact: Critical 1 critical-severity rules
- Prevention: Documented 2 fix examples

**OWASP:** Insecure Design (A04:2021-Insecure Design) - #4

## Description

When systems fail open, an error condition can bypass security controls. For example, a firewall that allows all traffic when it crashes is failing open. Systems should fail closed (deny by default).

## Prevention

Prevention strategies for Not Failing Securely based on 2 Shoulder detection rules.

### Go

Return false or deny access when security validation encounters errors

### Node.js

Always deny access when security checks encounter errors instead of calling next()

## Warning Signs

- [CRITICAL] Security check at ... grants access when error occurs
- [CRITICAL] security checks (authentication, authorization, validation) that grant
access when an error occurs i

## Consequences

- Bypass Protection Mechanism
- Gain Privileges

## Mitigations

- Design systems to fail closed (deny by default)
- Implement comprehensive error handling
- Test failure scenarios during security testing

## Detection

- Total rules: 2
- Critical: 1
- Languages: go, javascript, typescript

## Rules by Language

### Go (1 rules)

- **Failing Open on Error** [HIGH]: Security validation returns true/grants access when an error occurs.
  - Remediation: Return false or deny access when validation errors occur (fail closed).

```go
func validateToken(token string) bool {
    valid, err := checkToken(token)
    if err != nil {
        return false // Deny on error
    }
    return valid
}
```

Learn more: https://shoulder.dev/learn/go/cwe-636/failing-open

### Javascript (1 rules)

- **Failing Open on Security Check Errors** [CRITICAL]: Detects security checks (authentication, authorization, validation) that grant
access when an error occurs instead of denying it. This is a critical security
flaw where the system "fails open" rather than "failing closed/secure".

When authentication or authorization checks encounter errors, the system should
DENY access by default, not grant it.
  - Remediation: Always fail secure (deny access) when security checks encounter errors.

Correct pattern:
```javascript
// ✅ SAFE - Fails closed/secure
try {
  const user = await verifyToken(token);
  req.user = user;
  next(); // Only continue on success
} catch (error) {
  logger.error('Auth failed:', error);
  return res.status(401).json({ error: 'Unauthorized' });
  // Or: next(error) to trigger error handler
}
```

### Typescript (1 rules)

- **Failing Open on Security Check Errors** [CRITICAL]: Detects security checks (authentication, authorization, validation) that grant
access when an error occurs instead of denying it. This is a critical security
flaw where the system "fails open" rather than "failing closed/secure".

When authentication or authorization checks encounter errors, the system should
DENY access by default, not grant it.
  - Remediation: Always fail secure (deny access) when security checks encounter errors.

Correct pattern:
```javascript
// ✅ SAFE - Fails closed/secure
try {
  const user = await verifyToken(token);
  req.user = user;
  next(); // Only continue on success
} catch (error) {
  logger.error('Auth failed:', error);
  return res.status(401).json({ error: 'Unauthorized' });
  // Or: next(error) to trigger error handler
}
```