A02:2025 - Security Misconfiguration

Security Misconfiguration climbs to the number-two position in the OWASP Top 10 for 2025, up from A05 in the 2021 edition. Testing found that 90% of applications had some form of misconfiguration, with an average incidence rate of 4.5%. As applications grow more configurable and infrastructure shifts toward cloud-native architectures, the attack surface created by default settings, leftover debug flags, and missing hardening continues to expand.

Overview

Security misconfiguration occurs when an application, framework, web server, database, or cloud service is configured with insecure defaults, left incomplete, or set up with overly permissive options. Unlike coding flaws that require writing vulnerable logic, misconfigurations stem from what is left unchanged or forgotten. A single exposed admin console, an enabled debug flag, or a missing security header can give attackers a foothold. Radar's SAST engine scans source code and configuration files to identify these issues before deployment, catching them when they are cheapest to fix.

What Radar Detects

• Debug mode enabled in production. Framework-specific debug flags left active, such as Django's DEBUG=True, Flask's app.debug, or Express development mode. These expose detailed error information, internal paths, and sometimes interactive debuggers to end users.

• Verbose error messages. Exception handlers that return full stack traces, SQL error details, or internal variable dumps to the client. These messages give attackers precise information about the technology stack and application internals.

• Insecure defaults. Sample accounts, factory credentials, enabled admin consoles, default welcome pages, and example configurations shipped with frameworks that were never removed before deployment.

• Unnecessary features enabled. HTTP methods that should be disabled (TRACE, OPTIONS responding to all origins), wildcard CORS policies, exposed admin endpoints, and auto-generated API documentation served in production.

• Missing security headers. Responses that lack critical headers: X-Content-Type-Options: nosniff, X-Frame-Options, Strict-Transport-Security (HSTS), and Content-Security-Policy (CSP). Each missing header removes a layer of defense against common browser-based attacks.

• XML External Entity (XXE) processing enabled. XML parsers configured with default settings that allow external entity resolution, enabling attackers to read local files, trigger SSRF, or cause denial of service through entity expansion.

Related CWEs

CWE-611 (Improper Restriction of XML External Entity Reference), CWE-16 (Configuration), CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

See the CWE Reference for details.

Prevention

• Establish a repeatable, automated hardening process that produces identical secure configurations across development, staging, and production environments.
• Remove or disable all unused features, frameworks, sample code, documentation endpoints, and default accounts before deployment.
• Review and update configurations as part of every patch management cycle. Treat configuration drift as a security issue.
• Integrate automated configuration scanning into CI/CD pipelines so that misconfiguration is caught on every build, not just during periodic audits.
• Replace verbose error pages with generic user-facing messages while logging full details server-side for debugging purposes.
• Disable XML external entity processing in all XML parsers by default and enable it only when explicitly required with strict controls.
• Implement a complete set of security headers across all responses and verify them with automated tests.
• Segment application architecture so that administrative interfaces, management ports, and diagnostic endpoints are not exposed to the public network.

Next Steps