require-secure-defaults

Keywords: require secure defaults, security, ESLint rule, CWE-1188, secure-by-default, configuration, hardened CWE: CWE-1188: Insecure Default Initialization
OWASP Mobile: OWASP Mobile Top 10 M8: Security Misconfiguration

CWE: CWE-1188

ESLint Rule: require-secure-defaults. This rule is part of eslint-plugin-secure-coding.

Quick Summary

Vulnerability and Risk

Vulnerability: Insecure default initialization occurs when an application or its dependent libraries are configured with security features explicitly disabled (e.g., secure: false, strictSSL: false).

Risk: Software should be secure by default. Developers often disable security features during development and inadvertently leave these insecure settings in production code, leaving the application vulnerable to various attacks depending on the disabled feature.

Error Message Format

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

🔒 CWE-1188 OWASP:M8 | Insecure secure defaults detected | MEDIUM [Hardening]
   Fix: Enforce "Secure by Default" principle; enable security features | https://cwe.mitre.org/data/definitions/1188.html

Message Components

Rule Details

This rule helps identify instances where common property names associated with security (like secure, strictSSL, verify) are explicitly set to false.

Why This Matters

Configuration

This rule has no configuration options in the current version.

Examples

❌ Incorrect

// Disabling secure cookies
const sessionOptions = {
  cookie: {
    secure: false, // ❌ HIGH RISK
    httpOnly: true,
  },
};

// Disabling SSL validation in a request library
const clientOptions = {
  strictSSL: false, // ❌ HIGH RISK
  timeout: 5000,
};

// Disabling signature verification
const jwtConfig = {
  verify: false, // ❌ HIGH RISK
};

✅ Correct

// Enabling secure cookies (default should be true)
const sessionOptions = {
  cookie: {
    secure: true,
    httpOnly: true,
  },
};

// Keeping SSL validation enabled
const clientOptions = {
  strictSSL: true,
  timeout: 5000,
};

// Enforcing JWT signature verification
const jwtConfig = {
  verify: true,
};

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Non-Literal Values

Why: This rule only checks for explicit boolean false literals.

const isDev = process.env.NODE_ENV === 'development';
const options = {
  secure: isDev ? false : true, // ❌ NOT DETECTED
};

Mitigation: Use environment-specific configuration files that are strictly audited.

Unique Property Names

Why: Many libraries use custom names for their security settings.

Mitigation: Regularly audit the documentation for all sensitive libraries and ensure security-related settings are hardened.

References

• CWE-1188: Insecure Default Initialization
• OWASP Secure Product Design - Secure by Default
• NIST Security by Design Principles