no-self-signed-certs

Type-unaware

Detects disabling of TLS certificate validation via rejectUnauthorized: false or NODE_TLS_REJECT_UNAUTHORIZED=0. This rule is part of eslint-plugin-node-security and provides LLM-optimized error messages with fix suggestions.

🚨 Security rule | 💡 Provides suggestions | ⚠️ Set to error in recommended

Quick Summary

Aspect	Details
CWE Reference	CWE-295 (Certificate Issues)
Severity	Critical (security vulnerability)
Auto-Fix	💡 Suggests enabling validation
Category	Security
ESLint MCP	✅ Optimized for ESLint MCP integration
Best For	Node.js applications making HTTPS requests

Vulnerability and Risk

Vulnerability: Setting rejectUnauthorized: false disables TLS certificate validation entirely. This means the application will accept ANY certificate, including self-signed, expired, and certificates for different domains.

Risk: An attacker performing a man-in-the-middle (MITM) attack can intercept all traffic, read sensitive data, and inject malicious responses. The application cannot distinguish between the legitimate server and the attacker.

Rule Details

This rule detects:

rejectUnauthorized: false in TLS/HTTPS options
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'

Why This Matters

Risk	Impact	Solution
🕵️ MITM Attack	Attacker can read/modify all traffic	Enable certificate validation
🔓 Data Interception	Credentials, tokens, PII exposed	Use proper CA certificates
🔒 Compliance	Fails PCI-DSS, HIPAA, SOC2 requirements	Never disable in production

Configuration

Option	Type	Default	Description
`allowInTests`	`boolean`	`false`	Allow in test files

{
  rules: {
    'node-security/no-self-signed-certs': ['error', {
      allowInTests: true // Only for mocked services in tests
    }]
  }
}

Examples

❌ Incorrect

import https from 'https';
import axios from 'axios';

// Disabling certificate validation - CRITICAL risk
https.request({
  hostname: 'api.example.com',
  rejectUnauthorized: false, // ❌ Allows MITM attacks
});

// Same issue with axios
axios.get('https://api.example.com', {
  httpsAgent: new https.Agent({
    rejectUnauthorized: false, // ❌ Also vulnerable
  }),
});

// Global disable - affects ALL requests
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'; // ❌ Never do this

✅ Correct

import https from 'https';
import fs from 'fs';

// Default behavior - validation enabled
https.request({
  hostname: 'api.example.com',
  // rejectUnauthorized defaults to true
});

// Use custom CA for internal services
const ca = fs.readFileSync('/path/to/internal-ca.pem');
https.request({
  hostname: 'internal-api.company.com',
  ca: ca, // Custom CA for internal PKI
  rejectUnauthorized: true, // ✅ Explicitly enabled
});

// Pin specific certificate for high-security
const https = require('https');
const tls = require('tls');
const options = {
  hostname: 'api.example.com',
  checkServerIdentity: (host, cert) => {
    // Custom certificate verification
    if (cert.fingerprint !== expectedFingerprint) {
      return new Error('Certificate mismatch');
    }
  },
};

Security Impact

Vulnerability	CWE	OWASP	CVSS	Impact
Certificate Validation	295	A07:2021	9.1 Critical	Complete MITM capability
Improper Authentication	287	A07:2021	8.1 High	Server impersonation

Common Scenarios Where This Appears

Development with Self-Signed Certs

// ❌ Wrong: Disabling validation
rejectUnauthorized: false;

// ✅ Right: Add dev CA to trust store
ca: fs.readFileSync('./dev-ca.pem');

Internal Services

// ❌ Wrong: Disabling for internal APIs
rejectUnauthorized: false;

// ✅ Right: Use internal PKI with proper CA
ca: fs.readFileSync('/etc/pki/internal-ca.pem');

Legacy Systems

// ❌ Wrong: Disabling for old systems
rejectUnauthorized: false;

// ✅ Right: Update certificates or use TLS proxy

Migration Guide

Phase 1: Discovery

{
  rules: {
    'node-security/no-self-signed-certs': 'warn'
  }
}

Phase 2: Fix

For internal services: Set up proper internal CA
For development: Use mkcert for trusted local certs
For production: Use Let's Encrypt or commercial CA

Phase 3: Enforcement

{
  rules: {
    'node-security/no-self-signed-certs': 'error'
  }
}

require-secure-credential-storage - Secure credential storage
no-hardcoded-credentials - Detect hardcoded credentials

Known False Negatives

The rule matches a literal false on a rejectUnauthorized key, and a static '0' / `0` / 0 written to process.env.NODE_TLS_REJECT_UNAUTHORIZED (or globalThis.process.env…). Where the object or the assignment sits does not matter — an agent built inside an axios interceptor is reported like any other.

Values that are not a literal

Why: The rule does not follow data flow.

// ❌ NOT DETECTED
const insecure = false;
new https.Agent({ rejectUnauthorized: insecure });

The env switch passed to a child process

Why: Only an assignment to process.env is checked, not an env object handed to spawn/fork.

// ❌ NOT DETECTED
spawn('node', ['job.js'], {
  env: { ...process.env, NODE_TLS_REJECT_UNAUTHORIZED: '0' },
});

Mitigation: Audit all HTTP client configurations.

⚙️ Options

Option	Type	Default	Description
`allowInTests`	`boolean`	`false`	Allow in test files

Use this rule

npm install -D oxlint-plugin-node-security

.oxlintrc.json

{  "jsPlugins": ["oxlint-plugin-node-security"],  "rules": {    "node-security/no-self-signed-certs": "error"  }}

vite.config.ts

import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-node-security'],    rules: {      'node-security/no-self-signed-certs': 'error',    },  },});

oxlint-plugin-node-security re-exports eslint-plugin-node-security/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.

Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.

Follow the benchmarks Star on GitHub

no-self-signed-certs

Quick SummaryCopy Anchor Link

Vulnerability and RiskCopy Anchor Link

Rule DetailsCopy Anchor Link

Why This MattersCopy Anchor Link

ConfigurationCopy Anchor Link

ExamplesCopy Anchor Link

❌ IncorrectCopy Anchor Link

✅ CorrectCopy Anchor Link

Security ImpactCopy Anchor Link

Common Scenarios Where This AppearsCopy Anchor Link

Development with Self-Signed CertsCopy Anchor Link

Internal ServicesCopy Anchor Link

Legacy SystemsCopy Anchor Link

Migration GuideCopy Anchor Link

Phase 1: DiscoveryCopy Anchor Link

Phase 2: FixCopy Anchor Link

Phase 3: EnforcementCopy Anchor Link

Related RulesCopy Anchor Link

Known False NegativesCopy Anchor Link

Values that are not a literalCopy Anchor Link

The env switch passed to a child processCopy Anchor Link

Further ReadingCopy Anchor Link

⚙️ OptionsCopy Anchor Link