- Misconfiguration is an incorrect or overly permissive setting in a system, application, or cloud environment that creates an avoidable security gap, distinct from a software vulnerability.
- The Open Web Application Security Project (OWASP) lists security misconfiguration as its own top 10 risk category, and it appeared in 90 percent of applications OWASP tested.
- Cloud storage, firewalls, DNS records, and access control lists are the most common places where misconfigurations occur, often because default settings are never hardened.
- Some of the largest data exposures on record, including the Capital One breach and the Exactis data leak, trace back to a single misconfigured control rather than a novel exploit.
- Preventing misconfiguration requires continuous configuration monitoring, not a one-time audit, because settings drift as systems, teams, and cloud environments change.
What Is a Misconfiguration?
A misconfiguration is an incorrect or suboptimal setting in a system, application, network device, or cloud service that departs from secure defaults or established best practice and can expose data or infrastructure to unauthorized access.
Security misconfiguration is the term most often used interchangeably with misconfiguration in industry reporting and standards bodies.
Misconfigurations show up in firewalls left open on unnecessary ports, cloud storage buckets set to public instead of private, databases running with default administrative credentials, and DNS records that route traffic incorrectly. Unlike a software flaw that requires a patch, a misconfiguration is a setting choice, which means it can be introduced or reversed at any time, by any person with the right access, without writing a single line of code. That makes it one of the most common and most preventable causes of security incidents across cloud, network, and application environments today.
How Misconfigurations Happen
A misconfiguration is rarely the result of a single mistake. In 2023, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) published a joint advisory, based on their red team, blue team, and hunt and incident response assessments across large organizations, documenting ten misconfigurations found repeatedly, even inside mature security programs. The advisory's central finding was that misconfiguration is a systemic, recurring condition, not a one-time setup error.
The most common mechanisms behind misconfiguration include the following:
| Mechanism | How it creates risk |
|---|---|
| Unchanged default settings | Vendor defaults, including default credentials and default-open ports, are documented publicly and are the first thing an attacker checks. |
| Overly permissive access | Accounts, roles, or storage objects granted broader permissions than the task requires expand what an attacker can reach after one compromise. |
| Insufficient monitoring and segmentation | Flat networks and unlogged configuration changes let a single misconfigured entry point turn into broad access. |
| Poor patch and configuration management | Systems that fall out of sync with an organization's security baseline accumulate gaps faster than teams can track them. |
| Weak or bypassable multi-factor authentication | Multi-factor authentication (MFA) that is optional, poorly enforced, or missing on legacy protocols leaves a configuration gap attackers actively target. |
| Insufficient access control lists | Access control lists that are too broad, outdated, or inconsistently applied allow lateral movement between systems that should be isolated. |
Cloud environments add a further layer of risk: identity and tenant-boundary misconfigurations, such as an improperly scoped access token or an authentication flaw between customer accounts, can expose data across an entire multi-tenant service rather than a single system.
Types of Security Misconfiguration: Cloud, Firewall, DNS, and Access Control Examples
Security misconfiguration examples appear at nearly every layer of the technology stack. The table below breaks down the most common categories and what they look like in practice.
| Category | Common example |
|---|---|
| Cloud misconfiguration | A storage bucket, database, or backup snapshot set to public instead of private, exposing its contents to anyone with the link. |
| Firewall misconfiguration | Overly broad rules, unnecessary open ports, or a rule change that unintentionally exposes an internal service to the internet. |
| DNS misconfiguration | Stale or incorrect DNS records, including unclaimed subdomains that point to decommissioned cloud resources, which attackers can hijack. |
| Access control misconfiguration | Accounts or service roles granted administrator-level permissions when a narrower role would suffice. |
| Application misconfiguration | Debug mode left enabled in production, verbose error messages that reveal system details, or default administrative accounts left active. |
| Database misconfiguration | Databases exposed to the internet without authentication, or default credentials that were never changed after deployment. |
Cloud misconfiguration deserves particular attention within broader cloud security efforts because it scales differently than an on-premises mistake. A single incorrect setting applied through infrastructure-as-code or a shared template can propagate across dozens of environments in seconds, and a public cloud storage bucket is discoverable by automated scanners within minutes of being created. In 2019, a third-party developer left more than 540 million records, including account names, IDs, and comments, on a publicly accessible cloud storage bucket that had no password protection, illustrating how quickly a single configuration choice can expose data at scale.
Security Misconfiguration and the OWASP Top 10
The OWASP Top 10:2021 lists security misconfiguration as category A05, one of the most consistently ranked risks across every version of the list. Testing across the applications OWASP surveyed found that 90 percent showed some form of security misconfiguration, with an average incidence rate of 4.51 percent and more than 208,000 occurrences of related Common Weakness Enumeration (CWE) entries. The most frequently mapped weaknesses include CWE-16, which covers general configuration issues, and CWE-611, improper restriction of XML external entity reference, which affects XML processors that trust external entities by default.
Standards bodies treat misconfiguration and vulnerability as related but distinct concepts. Vulnerabilities are catalogued through the Common Vulnerabilities and Exposures (CVE) system, while misconfigurations are catalogued separately through the Common Configuration Enumeration (CCE), maintained by NIST. The Security Content Automation Protocol (SCAP) treats vulnerability scanning and configuration assessment as separate, complementary activities rather than a single check, which is why a system can pass a vulnerability scan and still carry significant misconfiguration risk.
Why Misconfiguration Matters for Data Security
Several of the largest data exposures on record trace back to a single misconfigured control rather than a novel technical exploit.
- In the 2019 Capital One breach, an attacker exploited what the company described as a specific configuration vulnerability in its infrastructure to access more than 100 million customer records in the United States and about 6 million in Canada.
- In 2018, the marketing and data aggregation firm Exactis left a database of roughly 340 million records, about 230 million on consumers and 110 million on business contacts, exposed on a publicly accessible server, where a security researcher discovered it before any confirmed criminal access.
Misconfiguration risk is not limited to legacy infrastructure. In 2021, default-public data feeds exposed roughly 38 million records across 47 organizations because a set of data connectors were public by default unless an administrator manually restricted them, a configuration choice rather than a coding flaw. More recently, independent security researchers found that a misconfigured cloud storage access token, scoped to grant full control over an entire storage account instead of a single file, exposed tens of terabytes of internal data, and, in a separate case, an identity misconfiguration in a multi-tenant cloud platform could have allowed cross-tenant access across an estimated one in four such applications.
These incidents show why misconfiguration matters for data security specifically: it is frequently the mechanism that turns a properly built system into an open door, independent of whether the underlying code has any flaws at all.
Understanding where sensitive data lives and how it moves is central to closing this gap. Data security posture management (DSPM) tools are built specifically to surface misconfigured cloud data stores, overly permissive access, and unmonitored data before attackers find them.
Common Misconfiguration Risks and Misconceptions
- Misconfiguration is not the same as a vulnerability. A vulnerability is a flaw in code; a misconfiguration is an incorrect setting. NIST's SCAP framework tracks them separately, and a fully patched system can still be badly misconfigured.
- Misconfiguration is not a one-time fix. Configuration drift happens continuously as systems, teams, and cloud environments change, which is why the CISA and NSA advisory found the same misconfigurations recurring even in organizations with mature security programs.
- Misconfiguration is not one problem; it spans roughly ten recurring categories. CISA and NSA's taxonomy covers defaults, privilege separation, monitoring, segmentation, patching, MFA, and access control lists, among others, so a single fix rarely closes the full gap.
- Blaming the end user is not always the right frame. After the 2021 default-public data feed exposure, security researchers argued that when a product's default setting is unsafe and difficult to discover, the more durable fix is for the product to change its defaults, not for every customer to be expected to find and correct the setting manually.
- Generative AI and copilot tools introduce a newer version of the same problem. Overly broad connector permissions and default-public sharing settings on AI-generated outputs can expose sensitive data the same way a public storage bucket does, often before security teams realize the tool has access to it.
How to Prevent and Fix Misconfiguration
- Start from secure-by-default settings
Configure systems so the safest option, such as private access or minimal permissions, is the default, rather than requiring every user to opt into security. - Apply the principle of least privilege
Grant accounts, roles, and service identities only the access required for their function, and review that access on a recurring schedule rather than at setup only. - Continuously monitor configuration, not just vulnerabilities
Automated configuration scanning against a recognized baseline, such as CIS Benchmarks, catches drift that a one-time audit misses. - Apply network segmentation across cloud environments
Isolate systems so a single misconfigured entry point cannot expose an entire environment. - Enforce multi-factor authentication consistently
Close gaps in legacy protocols and administrative accounts, where MFA is most often skipped. - Patch and update on a defined cadence
Outdated systems accumulate configuration gaps faster than teams can track manually. - Audit access control lists, DNS records, and firewall rules regularly
Remove stale entries, unclaimed subdomains, and overly broad rules before they become an exposure.
How Cyberhaven Addresses Misconfiguration
Cyberhaven addresses misconfiguration through a unified data security platform that combines DSPM and Data Lineage to find where sensitive data is exposed by a misconfigured system and trace how it got there. Unlike point tools that flag a misconfigured setting in isolation, Cyberhaven's platform connects that finding to the actual data at risk, giving security teams a prioritized view of which misconfigurations matter most because of what they expose.
DSPM continuously discovers and classifies data across cloud environments, surfacing storage, databases, and access configurations that depart from secure defaults, including overly permissive sharing settings and public exposure. Data Lineage then tracks the origin and movement of that data, so when a misconfiguration is found, security teams can see exactly which data sets were exposed, where they came from, and everywhere they subsequently moved, rather than treating the misconfigured system as an isolated incident.
Frequently Asked Questions
What is an example of a security misconfiguration?
A common example is a cloud storage bucket left set to public instead of private, exposing its contents to anyone with the link. Other examples include a firewall rule that unintentionally opens an internal service to the internet, default administrative credentials that were never changed, and debug mode left enabled in a production application.
What is the difference between a misconfiguration and a vulnerability?
A vulnerability is a flaw in software code that can be exploited, typically fixed with a patch. A misconfiguration is an incorrect or overly permissive setting, such as a public storage bucket or an open port, that exists independent of any code flaw. NIST's Security Content Automation Protocol tracks vulnerability scanning and configuration assessment as separate, complementary practices.
How does OWASP define security misconfiguration?
OWASP lists security misconfiguration as category A05 in its Top 10:2021 list of application security risks. It found that 90 percent of applications tested showed some form of security misconfiguration, with an average incidence rate of 4.51 percent and more than 208,000 occurrences of related CWE weaknesses, including issues mapped to CWE-16 and CWE-611.
What does cloud misconfiguration look like?
Cloud misconfiguration typically involves storage, databases, or access settings that default to broader access than intended, such as a public storage bucket, an overly permissive identity role, or an improperly scoped access token. Because cloud infrastructure is often deployed through shared templates, a single misconfigured setting can propagate across multiple environments quickly.
How do you fix a security misconfiguration?
Fixing a security misconfiguration starts with identifying the incorrect setting through continuous configuration monitoring rather than a one-time review, then correcting it against a recognized secure baseline such as CIS Benchmarks. Because configuration drift is ongoing, the most durable fix combines secure-by-default settings, least-privilege access, and recurring audits rather than a single correction.
What is a common misconfiguration mistake in firewalls or DNS?
A common firewall misconfiguration is an overly broad rule or an unnecessary open port that exposes an internal service to the internet. A common DNS misconfiguration is a stale or unclaimed subdomain record that still points to a decommissioned cloud resource, which attackers can claim and use to impersonate the organization.
.avif)
.avif)
