What Is a Security Misconfiguration, and How Do You Find One?

A security misconfiguration is a setting, permission or default that was left wrong, giving attackers a way in without needing to break any software. It is one of the most common causes of real-world compromise, and it is usually fixable in an afternoon once you know where to look.

What is a security misconfiguration?

A security misconfiguration is a setting, permission or default left in the wrong state, so a system that works perfectly well is also open to attack. OWASP puts it plainly: it is when a system, application or cloud service is “set up incorrectly from a security perspective”.

This is not a coding bug. The software does what it was built to do. The problem is how someone set it up, or what they left behind afterwards.

Common examples include:

• an admin account that still uses the vendor’s default password;
• a cloud storage bucket shared with anyone who has the link;
• a test or sample application nobody removed after go-live;
• error pages that print stack traces and version numbers;
• a remote access port open to the whole internet when only two people need it.

Why does security misconfiguration matter so much?

Because it is everywhere, and attackers know it. In the 2025 edition of the OWASP Top 10, this category climbed from fifth place to second. OWASP reports that every application it tested (100%) showed some form of misconfiguration, with an average incidence rate of 3.00% and more than 719,000 recorded occurrences.

The NSA and CISA reached a similar view from the other direction. Their joint advisory drew on red and blue team work and on CISA assessments of more than 1,000 network enclaves. Its top ten misconfigurations read like a checklist of ordinary IT decisions, not exotic exploits.

So this should worry a small or mid-sized business more than a headline zero-day. A patch fixes a flaw, but nobody ships a patch for the way your team set the thing up. If you get it wrong, the fix is yours to make.

What are the most common security misconfigurations?

The NSA and CISA advisory names ten. They are worth reading in full, but here is the short version in plain English.

1. Default configurations of software and applications.
2. Improper separation of user and administrator privilege.
3. Insufficient internal network monitoring.
4. Lack of network segmentation.
5. Poor patch management.
6. Bypass of system access controls.
7. Weak or misconfigured multifactor authentication.
8. Insufficient access control lists on network shares and services.
9. Poor credential hygiene.
10. Unrestricted code execution.

OWASP adds a web application view. Its example scenarios include sample applications left on a server with default credentials, directory listing that exposes compiled code, verbose error messages that reveal component versions, and cloud storage with overly permissive sharing settings.

Notice how many of these need no clever exploit. Because the weakness is already there, an attacker only has to look.

How do misconfigured systems end up in production?

Rarely through carelessness alone. Most come from pressure and drift, and each cause below is easy to spot once you look for it.

• Speed. A developer opens a port to test something on Friday and the change never gets reversed.
• Defaults. Vendors ship products with easy setup in mind. The NSA and CISA advisory lists default configurations of software and applications as the first item on its list.
• Complexity. Cloud platforms have hundreds of settings. Nobody holds them all in their head, and a permissive option can look harmless in a console.
• Drift. A system that was locked down at launch slowly changes as people add accounts, exceptions and integrations.
• No owner. When nobody is responsible for reviewing settings, nobody reviews them.

How do you find a security misconfiguration before an attacker does?

Start with the dull inventory work, because you cannot check settings on systems you do not know about. Then work through these steps.

1. List what you run. Servers, cloud accounts, SaaS admin panels, network devices, and anything internet-facing.
2. Compare against a baseline. Use a hardening guide for each platform and note every gap.
3. Check who can reach what. Review firewall rules, sharing links and admin roles, and remove anything nobody can justify.
4. Automate the repeat checks. OWASP advises automating configuration verification across environments, so drift gets caught early.
5. Get an outside view. Someone who did not build the system is far better at spotting what is wrong with it.

That last step is where testing earns its keep. A server build review compares an individual machine against secure build standards with privileged access. A penetration test looks at the same weaknesses from an attacker’s side, and shows which ones can actually be chained into a break-in. Vulnerability scanners catch some of this. However, they tend to miss context, such as a file share that is technically allowed but should never be open to every staff account.

How can you prevent security misconfiguration?

You will never get to zero. Still, a few habits cut the risk sharply, and most cost nothing but time.

• Harden by default. Build every new system from the same locked-down template, and remove unused features, accounts and sample content.
• Change every default credential before a system goes near a network.
• Apply least privilege. People and services should get the access their job needs, and no more.
• Keep secrets out of code. OWASP recommends avoiding hardcoded credentials in favour of identity federation and role-based access.
• Use security headers on web applications, and turn off detailed error messages for the public.
• Review on a schedule. Put configuration reviews in the calendar, and after every major change.
• Write it down. Someone should own each system’s settings, and the owner should be a named person.

If you work towards Cyber Essentials, many of these overlap with its secure configuration theme. Our piece on Cyber Essentials and penetration testing explains where the certificate stops and testing begins.

Where can you get help with it?

Many firms fix the easy items and then wonder what they have missed. That gap is normal, because people rarely spot the flaws in systems they built themselves.

If you would rather have an independent view of your settings, Aardwolf Security can scope a penetration test around the systems that matter most to your business. You can get in touch to talk through what would suit you. Either way, the checklist above works without us, so start there if you are not ready to talk.

Security misconfiguration FAQ

Is a misconfiguration the same as a vulnerability?

Not quite. A vulnerability is a flaw in the software itself, so the fix is usually a patch from the vendor. A misconfiguration is a choice about how the software is set up, so the fix is on your side. The two overlap, though: OWASP’s 2025 data for this category includes 1,375 CVEs.

Are misconfigurations only a cloud problem?

No. Cloud services make them easy to create at scale, but the NSA and CISA list covers ordinary networks, including segmentation, monitoring and network share permissions.

Can a vulnerability scanner find them?

Some, yes, such as default credentials and missing headers. Others depend on context, so a person has to judge them. A scanner cannot know that a shared folder is a problem for your business in particular.

How often should configurations be reviewed?

Review them after any significant change, and at least once a year for critical systems. Automated checks can run far more often, which is why they are worth setting up.