Security Misconfiguration is the risk that arises when a system is deployed with insecure default settings, unnecessary features enabled, or hardening steps skipped — and it sits at number five on the OWASP Top 10 (2021). Unlike a coding bug, a misconfiguration is a gap between how software could be secured and how it was actually set up. The 2021 revision also absorbed XML External Entities (XXE) into this category, recognizing that XXE is almost always the result of leaving an XML parser configured with dangerous defaults. This guide covers what the category includes, why it is so common, the incidents that define it, and how to harden systematically.
What OWASP A05 actually covers
A05:2021 maps to 20 CWEs, including CWE-16 (configuration), CWE-260 (password in configuration file), CWE-315 (cleartext storage in a cookie), CWE-611 (improper restriction of XML external entity reference, the XXE weakness), and CWE-1188 (insecure default initialization). OWASP describes the category broadly: missing hardening across any part of the stack, unnecessary features or ports enabled, default accounts and passwords left active, overly verbose error messages that leak stack traces, missing security headers, and out-of-date or permissive cloud permissions. Because it spans the whole stack — application server, framework, database, container, orchestrator, and cloud account — misconfiguration is less a single defect than a discipline problem: every layer ships with defaults optimized for getting started, not for staying secure.
Why it ranks number five
Misconfiguration ranks fifth because it is astonishingly common and highly automatable to exploit. OWASP's 2021 data set found the category in a large share of tested applications, and it moved up from sixth in 2017. The rise tracks the explosion of infrastructure surface: every team now runs cloud accounts, container registries, CI/CD systems, and managed data stores, each with its own configuration model and its own permissive defaults. Attackers scan the entire internet continuously for exposed databases, open admin panels, and misconfigured storage buckets, so a single forgotten default is found in hours, not months. The category's persistence is a direct consequence of speed: teams ship fast, defaults are convenient, and hardening is the step most easily skipped under deadline pressure.
Real-world examples
The Capital One breach in 2019 combined a server-side request forgery flaw with an over-permissive IAM role — a misconfiguration that let the attacker use a compromised instance's credentials to read more than 100 million customer records from cloud storage. Years of open Elasticsearch, MongoDB, and S3 exposures have leaked billions of records simply because a data store was internet-facing with authentication disabled by default. On the XXE side, CVE-2018-1000840 and a long line of similar flaws stem from XML parsers that resolve external entities unless explicitly told not to, allowing attackers to read local files or trigger server-side requests through a crafted document. In each case the software was capable of being secure; the deployment simply used the insecure default.
Vulnerable versus fixed code
XXE is the archetypal misconfiguration bug — an XML parser left in its dangerous default state.
// VULNERABLE: default parser resolves external entities (CWE-611, XXE)
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(untrustedXmlInput); // reads local files, SSRF
// FIXED: disable DTDs and external entities before parsing
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(untrustedXmlInput); // entities are inert
The fix does not touch application logic at all; it changes the parser's configuration to reject the document-type declarations and external entities that make XXE possible. That is the essence of the category — the same code is secure or vulnerable depending entirely on how the underlying component is configured.
Prevention checklist
- Establish a repeatable, hardened baseline configuration and deploy the same locked-down image to every environment.
- Remove or disable unused features, default accounts, sample apps, and open ports before going live.
- Turn off verbose errors and stack traces in production; return generic messages to users.
- Set security headers (Content-Security-Policy, HSTS, X-Content-Type-Options) and secure cookie flags.
- Disable DTD processing and external entities on every XML parser to eliminate XXE.
- Scan infrastructure-as-code (Terraform, Kubernetes manifests, cloud policies) for permissive defaults before deploy.
- Apply least privilege to cloud IAM roles and service accounts; audit them regularly.
- Keep configuration in version control and review changes the same way you review code.
How Safeguard helps
Misconfiguration lives at the boundary of code and infrastructure, and Safeguard covers both. Safeguard DAST probes running systems for the observable symptoms — missing security headers, exposed admin endpoints, verbose error pages, and XXE-vulnerable parsers — confirming which misconfigurations are actually reachable from the outside rather than merely present in a config file. Our SCA engine tracks the components and base images that ship with insecure defaults, and Griffin AI correlates configuration findings with your deployment context to distinguish a debug flag left on in production from the same flag harmlessly set in a local script. When a fix is mechanical, Auto-Fix opens a pull request that hardens the setting — disabling entity resolution, adding a header, tightening a permission — and the Safeguard CLI runs these checks in CI so a misconfiguration is caught before it reaches production.
Frequently Asked Questions
Why was XXE merged into Security Misconfiguration?
Because XML external entity attacks almost always succeed due to a parser being left in its permissive default state rather than a distinct coding flaw. Folding XXE into A05 in 2021 reflects that the fix is a configuration change — disabling DTDs and external entity resolution — which is exactly what the misconfiguration category is about.
Is a misconfiguration really a vulnerability if the code is fine?
Yes. The code being correct does not make the system secure if the environment around it is open. An exposed database with authentication disabled, a debug console reachable in production, or an over-permissive IAM role each creates a directly exploitable path regardless of application code quality. Attackers exploit the deployment, not just the source.
How is Security Misconfiguration different from Vulnerable Components?
Vulnerable and Outdated Components (A06) is about running software with known CVEs that need patching. Security Misconfiguration (A05) is about how software — even fully patched software — is set up: defaults, permissions, exposed features, and hardening. A component can be perfectly up to date and still be dangerously misconfigured, and vice versa.
What is the fastest way to reduce misconfiguration risk?
Standardize on a hardened, version-controlled baseline and deploy it identically everywhere, then scan infrastructure-as-code and running systems continuously against that baseline. Consistency is the win: most misconfiguration incidents come from one environment drifting from a known-good state, so removing manual, per-environment setup eliminates the drift that attackers rely on.
Ready to find misconfigurations before attackers scan for them? Start at app.safeguard.sh/register, or read the setup guide at docs.safeguard.sh.