Skip to content

CWE-15: External Control of System or Configuration Setting

Overview

This vulnerability occurs when user input controls a system or application configuration setting, letting an attacker change how the application behaves or weaken the security controls that configuration governs.

Relationship to Other CWEs

CWE-15 and the two broader classes MITRE files it under:

  • CWE-15 (this page) - untrusted input controls a configuration setting, changing how the application behaves or weakening the controls that setting governs.
  • CWE-20 (Improper Input Validation) - CWE-15 is the case where the unvalidated input reaches a configuration sink.
  • CWE-642 (External Control of Critical State Data) - CWE-15 is the case where the externally controlled state is a configuration setting rather than session or workflow state.

If a finding involves critical state broader than configuration, CWE-642 is likely the better fit.

OWASP Classification

A02:2025 - Security Misconfiguration

Risk

High: If external input can influence security-sensitive configuration, an attacker can weaken or disable a control the application depends on, or redirect its behavior. It usually acts as a bypass primitive: the configuration change is what makes another vulnerability reachable.

Remediation Steps

Core Principle: Never allow untrusted input to directly set configuration values; use an allowlist to constrain changes to known-safe values, require elevated authorization, and prefer immutable deployment-time configuration over runtime configuration changes.

Trace the Data Path

Work out how untrusted data reaches the configuration sink:

  • Source: Where untrusted data enters (HTTP parameters, request headers, POST body, cookies, query strings)
  • Sink: The configuration assignment (config.set(), os.environ[key] = value, System.setProperty(), environment variable assignment)
  • Validation gaps: Each frame between source and sink that lacks allowlist validation or an authorization check

Eliminate Runtime Configuration Control (Preferred)

The safest fix is to remove runtime configuration changes altogether:

  • Set all configuration at application startup via environment variables, config files, or secret managers
  • Never expose configuration-setting endpoints to end users
  • Treat configuration as immutable once the application starts
  • Use deployment-time mechanisms (CI/CD pipelines, infrastructure-as-code) to manage configuration changes

Restrict with an Allowlist (If Runtime Config Is Required)

If runtime configuration changes are a genuine product requirement, constrain them:

  • Define an explicit allowlist of permitted values for each configuration key
  • Reject any value not on the allowlist; do not attempt to sanitize it
  • Never accept arbitrary key names from user input; map user choices to internal keys
  • Validate type and range for numeric settings (a timeout must fall between 1 and 60 seconds, for example)
  • Restrict which settings users can change; security-critical settings must never be user-modifiable

Require Authorization for All Configuration Changes

Any endpoint that changes configuration must enforce access control:

  • Require authentication; unauthenticated users must never reach config endpoints
  • Require admin-level authorization; standard user roles must not be able to change configuration
  • Audit all changes: log who changed what, to what value, and when
  • Alert on unexpected configuration change attempts

Apply Least Privilege and Secure Defaults

Limit the blast radius if exploitation occurs:

  • Secure defaults: every configuration field defaults to its most restrictive safe value
  • Fail securely: if a change fails validation, revert to the previous secure value
  • Isolate configuration surfaces: admin interfaces are reachable only from internal networks

Test Configuration Manipulation Attempts

Verify the fix blocks malicious configuration changes:

  • Values outside the allowlist are rejected with no change applied
  • Shell metacharacters and path traversal (../../etc/passwd, ; rm -rf /) are rejected
  • Configuration endpoints return 401/403 without valid admin credentials
  • Numeric settings enforce their minimum and maximum bounds

Guard Against Untrusted Configuration Sources

A related but distinct attack: instead of setting individual values, the attacker controls where the application reads its configuration from.

  • User-supplied file path passed to a config parser (configparser.read(path), new FileInputStream(path)) - risks path traversal (../../etc/passwd), exposing internal files as parsed config
  • User-supplied URL fetched and parsed as configuration - risks SSRF against internal services such as the cloud metadata endpoint 169.254.169.254 (see CWE-918)
  • User-uploaded file (JSON, YAML, XML, .properties) applied directly as config - risks unsafe deserialization or code execution if the parser is not hardened (see CWE-502 and CWE-611)
  • Database rows that users can write to, later read back and applied as config without re-validation - a second-order issue that affects all users once one user's write is applied globally

The same defenses apply to these sources. Hardcode or allowlist the directory for any config file path and never accept one from a request. Hardcode internal config endpoints rather than fetching from a user-supplied URL. Use safe parsers for uploaded config (yaml.safe_load() not yaml.load(), external entity processing disabled, schema validation before applying values). Treat database-sourced config as untrusted input that needs the same allowlist and type checks as HTTP input.

Language-Specific Guidance

Framework-specific examples and patterns:

  • C# - ASP.NET Core IOptions<T> validation, LoggingLevelSwitch, safe config file loading
  • Java - Spring Boot @ConfigurationProperties, JSR-303 validation, @PreAuthorize, safe path loading
  • JavaScript - Node.js process.env immutability, dotenv, zod allowlist validation, safe URL loading
  • Python - Pydantic BaseSettings, Django/Flask config class patterns, yaml.safe_load()

Additional Resources