Cybersecurity glossary
What is Security Misconfiguration?
Learn what security misconfiguration is in the OWASP Top 10, how insecure defaults and unnecessary features expose applications, and how to harden configurations across stacks.
Definition
Security Misconfiguration is an OWASP Top 10 category (A05:2021) covering insecure or incomplete configuration of applications, frameworks, servers, cloud services, and permissions—including default credentials, unnecessary features, verbose errors, and missing security headers or patches.
Why security misconfiguration matters
Modern stacks are configurable by design. Every unused admin console, sample endpoint, open storage ACL, or leftover debug flag expands the attack surface. Security Misconfiguration (OWASP A05) remains one of the most common root causes because defaults favor convenience over lockdown.
Attackers automate discovery of these gaps. They do not need a novel exploit when /actuator, directory listing, or a public bucket is waiting.
How misconfiguration becomes an incident
Insecure default or feature enabled
Frameworks, cloud services, or containers ship with broad permissions, sample apps, or verbose modes.
Environment drifts from baseline
Manual changes, rushed hotfixes, or incomplete IaC leave production weaker than intended.
Attacker discovers the opening
Scanners and manual recon find open panels, headers missing, or excessive error detail.
Abuse and pivot
Initial access, data exposure, or foothold expands through the unnecessary capability left on.
Misconfiguration patterns to watch
Insecure defaults
Vendor passwords, open management ports, and permissive CORS or IAM left unchanged.
Unnecessary features
Sample apps, unused HTTP verbs, remote admin, and debug tooling reachable in prod.
Inconsistent hardening
Staging locked down while production—or one microservice—still exposes stack traces.
Cloud ACL mistakes
Public storage, overly broad roles, and security groups that allow the world to talk.
Hardening that sticks
| Control | Notes |
|---|---|
| Hardened baselines | Apply CIS-style or vendor hardening guides to OS, app servers, and frameworks |
| Disable unused features | Remove sample apps, unused endpoints, and debug tooling from production images |
| Least privilege | Tighten IAM, DB users, and network rules to the minimum needed |
| Security headers | Set CSP, HSTS, frame protections, and related headers consistently |
| Automated policy checks | Scan IaC and live config for drift and known insecure settings |
| Patch and rebuild | Keep platforms current; rebuild images rather than hand-editing pets |
- Inventory all exposed services, admin UIs, and cloud storage for each environment.
- Replace default credentials and rotate any that ever shipped in docs or images.
- Disable directory listing, sample apps, and unnecessary HTTP methods.
- Turn off detailed errors and debug endpoints outside tightly controlled break-glass access.
- Encode configuration in IaC and block merges that violate policy-as-code rules.
- Review CORS, CSP, and cookie flags as part of release gates.
- Run recurring CSPM / configuration scans and assign owners to findings.
- Verify production matches the hardened baseline after every major change.
The practical takeaway
Security Misconfiguration is insecure defaults, leftover features, and drifted settings. Define a hardened baseline, disable what you do not need, automate policy checks, and treat configuration as code you continuously verify—not a one-time checklist.
Related security terms
Information Disclosure
Data leakage often enabled by verbose or debug misconfiguration.
Debug Endpoint Exposure
Admin or debug surfaces left reachable in production.
Insecure Design
Missing controls at design time versus wrong settings at deploy time.
Content Security Policy (CSP)
A header-level control frequently omitted or mis-set in deployments.
Frequently asked questions
What is security misconfiguration in simple terms?
Something powerful was left on the wrong setting: defaults, open admin panels, unused services, overly broad cloud permissions, or debug modes in production.
How does OWASP A05 differ from insecure design?
Insecure design lacks required controls. Misconfiguration means controls or platforms exist but are set insecurely, incompletely, or inconsistently across environments.
What are common examples?
Default passwords, directory listing, sample apps left deployed, unnecessary HTTP methods, overly permissive CORS or IAM roles, and stack traces returned to users.
Why is cloud especially prone to this?
Cloud services expose many toggles—storage ACLs, security groups, keys, and identity policies. A single public bucket or open management port can expose large datasets.
How do teams detect misconfigurations?
Baseline hardening guides, infrastructure-as-code policy checks, CSPM tools, configuration drift detection, and regular reviews of exposed ports and features.
Does patching fix misconfiguration?
Patching addresses known software flaws. Misconfiguration is about settings and attack surface. You need both: patched software and hardened, reviewed configuration.
What is a repeatable fix approach?
Immutable hardened images, IaC with policy-as-code, least-privilege defaults, automated config tests in CI, and environment parity with secrets kept out of images.
References
Explore authoritative guidance and frameworks related to security misconfiguration.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.