Skip to content

CWE-16: Configuration

Overview

This finding was detected during dynamic (DAST) scanning and indicates a security misconfiguration in the running application or its environment.

CWE-16 is a category-level finding. The scanner has identified insecure configuration behavior, but further investigation is required to determine the specific misconfiguration and its impact.

Important: CWE-16 should be refined into a more specific misconfiguration (e.g., CWE-614, CWE-611, CWE-295) before closing the finding.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

The scanner observed insecure runtime behavior consistent with a configuration issue, such as:

  • Debug or verbose error output in production
  • Missing or insecure security headers
  • Overly permissive CORS configuration
  • Directory listing enabled
  • Default or weak credentials accepted
  • Insecure protocol or cipher usage

Note: CWE-16 is a broad category. You should identify the specific misconfiguration (e.g., debug enabled, missing HSTS, permissive CORS) and remediate that issue directly.

Mapping the Finding to Source Code and Configuration

CWE-16 findings usually map to configuration, not application logic.

Identify the Affected Layer

Determine where the configuration lives:

  • Application config (env vars, YAML, JSON, .env)
  • Framework settings (Django, Spring, ASP.NET)
  • Web server config (Nginx, Apache, IIS)
  • Reverse proxy / load balancer
  • Container or orchestration config

Locate Configuration Issues

Common patterns to search for:

  • Debug mode: DEBUG=True, NODE_ENV=development
  • Default credentials: Admin passwords not changed
  • Verbose errors: Stack traces in production
  • Unnecessary features: Enabled in production
  • Insecure defaults: No authentication required

Find Misconfigurations

Search for risky settings:

# Find debug/development mode
grep -r "DEBUG.*=.*True" src/
grep -r "development" config/
grep -r "trace" config/

Trace to Vulnerable Configuration

Look for security misconfigurations:

  • Debug mode in production: Detailed error messages, profiling
  • Directory listing: Enabled on web server
  • Default accounts: Not removed or secured
  • Unnecessary services: Running and exposed
  • Missing security headers: HSTS, CSP, X-Frame-Options
  • Permissive CORS: Access-Control-Allow-Origin: *

Remediation

Core principle: Production systems must run with secure, minimal, and explicitly reviewed configuration; insecure defaults must never be exposed.

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Check for debug mode
curl http://localhost/ | grep -i "debug\|stack\|trace"

# Check security headers
curl -I http://localhost/ | grep -i "x-frame\|strict-transport\|content-security"

# Check for directory listing
curl http://localhost/uploads/

Verify the Fix

  • Confirm debug mode disabled in production
  • Verify security headers present (HSTS, CSP, X-Frame-Options)
  • Check directory listing disabled
  • Ensure default credentials changed/removed
  • Test CORS properly restricted

Test Edge Cases

# Debug/verbose errors
curl http://localhost/nonexistent  # Should not show stack traces

# Security headers
curl -I "/" | grep -i "X-Frame-Options: DENY"
curl -I "/" | grep -i "Strict-Transport-Security"

# Directory listing
curl /static/ | grep "Index of"  # Should fail

# CORS
curl -H "Origin: https://evil.com" -I "/api/"
# Should NOT return: Access-Control-Allow-Origin: *

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources