Skip to content

CWE-16: Configuration

Overview

Configuration vulnerabilities occur when applications or systems are deployed with insecure settings, missing security controls, or defaults that expose attack surface. The category covers missing security headers, debug mode enabled in production, exposed administrative interfaces, default credentials, misconfigured authentication, and weak cryptographic settings. Most of these come from incomplete hardening or from not following a secure configuration baseline at deployment.

Relationship to Other CWEs

CWE-16 is a Category, and MITRE's mapping guidance for it is Prohibited. It is an organizational grouping for weaknesses "typically introduced during the configuration of the software", not a directly reportable weakness itself, and MITRE's wording is explicit: "This CWE ID must not be used to map to real-world vulnerabilities." MITRE instead points mappers to the specific weakness a misconfiguration actually produces, such as access-control issues (CWE-284 and its descendants) or resource management (CWE-400).

If a scanner or manual finding lands on this page, prefer the specific weakness it represents. Pages here that commonly correspond to configuration findings:

Use this page only for general configuration-hardening guidance when the finding does not map cleanly to one of the more specific weaknesses above.

OWASP Classification

A02:2025 - Security Misconfiguration

Risk

Low to High: Impact depends on the misconfiguration. A missing security header is low impact; a setting that enables authentication bypass, remote code execution, or data exposure is critical. Configuration weaknesses are a common finding and often give an attacker their first foothold.

Remediation Steps

Core Principle: Never deploy with default or insecure settings. Production deployments follow a hardening baseline: debug mode off, security headers set, and access restricted to what each component needs.

Identify the Specific Configuration Issue

Review the security scan results to determine the exact misconfiguration:

  • Security headers: Missing Content-Security-Policy, X-Frame-Options, HSTS, X-Content-Type-Options
  • Debug/Verbose mode: Stack traces visible, detailed error messages, development mode enabled
  • Default settings: Default admin credentials, sample applications, unnecessary services enabled
  • Exposed interfaces: Admin panels, database management tools, API documentation accessible without authentication
  • Weak TLS/SSL: Outdated protocols (SSLv2/v3, TLS 1.0, TLS 1.1), weak ciphers, missing certificate validation
  • Permissions: Overly permissive file/directory permissions, world-readable sensitive files

Apply Security Hardening

Apply the change that matches the finding:

Security Headers

Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

Debug/Production Mode

  • Set environment to production (NODE_ENV=production, DEBUG=false, app.debug = False)
  • Disable stack traces and verbose error messages for end users
  • Remove development/test accounts and endpoints

Default Credentials

  • Change all default passwords immediately
  • Remove or disable default administrative accounts
  • Require strong passwords for all accounts

Access Controls

  • Restrict admin interfaces to internal networks only
  • Require authentication for all sensitive endpoints
  • Use role-based access control (RBAC)

Follow Security Configuration Baselines

Use industry-standard hardening guides:

  • CIS Benchmarks: Center for Internet Security configuration standards
  • OWASP ASVS: Application Security Verification Standard configuration requirements
  • NIST SP 800-53: Security and Privacy Controls
  • Platform-specific guides: AWS Security Best Practices, Azure Security Baseline, etc.

Implement Configuration Management

  • Store configuration in version control, with secrets excluded
  • Use Terraform, CloudFormation, or Ansible so deployments are reproducible
  • Keep credentials in a secret manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault
  • Scan configurations automatically before deployment
  • Keep dev, staging, and production configurations separate

Regular Security Audits

  • Periodic configuration reviews against security baselines
  • Automated configuration scanning (e.g., AWS Config, Azure Policy)
  • Penetration testing to identify configuration weaknesses
  • Security header testing (securityheaders.com, Mozilla Observatory)

Additional Resources