# 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: Media 2 lenguajes cubiertos - Impact: Crítico 1 reglas de severidad crítica - Prevention: Documentada 2 ejemplos de corrección **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 Estrategias de prevención para Not Failing Securely basadas en 2 reglas de detección de Shoulder. ### Go Return false or deny access when security validation encounters errors ### JavaScript 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 - Eludir mecanismo de protección - Obtener privilegios ## Mitigations - Diseña sistemas que fallen cerrados (denegar por defecto) - Implementa un manejo de errores exhaustivo - Prueba escenarios de fallo durante las pruebas de seguridad ## 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 } ```