Christmas Came Early: Security Misconfigurations Jump to #2 on OWASP Top 10

If you're in application security or DevOps, November 2025 brought an early holiday surprise—but not the kind you want. OWASP released their 2025 Top 10 list, and Security Misconfiguration jumped from position #5 all the way up to #2, beaten only by Broken Access Control. This isn't just numbers moving around on a list—it's backed by real data showing that misconfigurations are becoming the easiest way into modern systems.

Here's the thing: 3% of all tested applications had at least one misconfiguration vulnerability. That might sound small, but think about it—we're talking about production systems handling your data, processing payments, storing personal information. When you're running hundreds of services across cloud platforms, Kubernetes clusters, databases, and deployment pipelines, that 3% adds up fast.

Why This Keeps Happening

The problem isn't that developers suddenly got lazy or careless. It's that building software has become ridiculously complex. Remember when an application just ran on one server? Now that same app might span multiple cloud providers, container platforms, serverless functions, and dozens of interconnected microservices. Each piece has its own configuration, and every configuration choice can create a security hole.

Think about what you're probably dealing with right now:

• Cloud stuff (AWS permissions, Azure security groups, Google Cloud firewall rules)
• Kubernetes settings (who can access what, network rules, how pods are locked down)
• Application configs (environment variables, feature flags, API keys)
• Database settings (who gets in, encryption, backups)
• Build and deployment pipelines (who can push code, deployment credentials, where artifacts live)
• Web server configs (TLS settings, CORS rules, security headers)

Each of these layers is another place where a wrong setting can create problems. An S3 bucket that's too open. A Kubernetes service account with admin access when it doesn't need it. A database sitting on the public internet with default passwords. A deployment pipeline that lets anyone push to production. These aren't made-up examples—this is happening right now.

What the Data Shows

OWASP looked at 2.8 million applications for this year's list—almost twice as many as 2021. Security Misconfiguration now covers 16 different types of weaknesses, from default passwords to badly protected config files.

The jump from #5 to #2 matches what people working in security have been seeing: configuration problems aren't rare mistakes anymore. They're built into how we work. OWASP put it well: "software engineering is continuing to increase the amount of an application's behavior that is based on configurations." And it's only getting worse.

Infrastructure as code was supposed to help with this. Define everything in version-controlled files, make it reproducible, make it auditable. And it does help—but we're also creating way more infrastructure than before. The amount of stuff we need to configure has exploded faster than our ability to keep it all secure.

What Actually Happens

Misconfigurations aren't just theoretical problems—they're how attackers actually get in. Research shows that about 80% of ransomware attacks involve misconfigurations somewhere along the way. Makes sense when you think about it: why hunt for complicated security flaws when you can just walk through a door someone left open?

Look at what's been happening:

• Databases with millions of customer records exposed because someone misconfigured cloud storage
• Kubernetes clusters taken over because permissions were set too loosely
• Build pipelines hijacked because deployment credentials weren't protected properly
• Applications breached through CORS settings that allowed requests from anywhere

Here's the frustrating part: in most of these cases, the actual code was fine. The developers followed best practices. The application logic was solid. But a configuration mistake created a path in that bypassed everything else.

The Usual Suspects

When you look at security audits and assessments, you see the same problems over and over:

Giving Too Much Access

This is the big one. It shows up everywhere:

• Cloud permissions set to "everything" (*) when they should be specific
• Kubernetes accounts with full admin rights used for everyday tasks
• Database users who can access everything when they only need a few tables
• Config files that anyone on the system can read

What makes this worse is how it happens. Someone needs to debug something, so they temporarily give themselves full access. They fix the problem, move on, and forget to lock things back down. Then that overly-permissive config ends up in production.

Admin Panels on the Public Internet

Management interfaces that should only be accessible internally end up exposed to everyone:

• Database admin tools (phpMyAdmin, MongoDB Express) sitting on the internet with no password
• Kubernetes control panels anyone can reach
• Docker management endpoints listening publicly
• Admin consoles for monitoring tools, message queues, orchestration systems

These tools are powerful and weren't built expecting to face constant attacks from the entire internet.

Default Passwords Still Everywhere

You'd think this would be solved by now, but it's still incredibly common:

• Databases running with "admin/admin" as the password
• Admin panels with well-known default credentials
• IoT devices you literally can't change the password on
• Service accounts with weak, predictable passwords

Automated scanners hammer these defaults constantly. When they work, attackers get deep access immediately.

Missing Basic Security Settings

Web applications and APIs often ship without fundamental protections:

• No Content Security Policy headers (or ones that don't do anything)
• CORS configs that allow requests from anywhere
• TLS set up to allow weak, outdated encryption
• Debug mode still on in production, showing detailed errors

Each of these either gives attackers information or creates a direct way in.

Infrastructure as Code: Helping or Making It Worse?

Tools like Terraform, CloudFormation, and Pulumi were supposed to fix this. Make infrastructure reproducible, keep it in version control, treat it like code. And they do work for that—but they created new problems.

When you configured servers by hand, a mistake usually only affected that one server. Now? A mistake in a Terraform module can instantly create hundreds of misconfigured resources. The blast radius got way bigger.

Think about a Terraform module that creates S3 buckets. If that module has permissions set too loosely, every single bucket created with it inherits that problem. Multiply that across dozens of modules and multiple teams, and you see how quickly things scale.

The good news is that infrastructure as code also makes it easier to catch problems automatically. You can scan Terraform files, Kubernetes configs, and CloudFormation templates before they get applied—catching misconfigurations before they make it to production.

How to Actually Catch These Problems

You need to check for misconfigurations at multiple stages—while you're writing code, when you're deploying, and after things are running.

Scan Your Config Files Before Deployment

Before configurations reach production, run them through automated checks. The tools for this have gotten a lot better:

• Infrastructure scanners look at your Terraform, CloudFormation, and Kubernetes files for security issues
• Container scanners check your Dockerfiles and images
• Policy frameworks like Open Policy Agent let you define security rules that configs must pass

CoGuard does something interesting here. Instead of just checking each config file by itself, they analyze how your configurations work together across your whole infrastructure—cloud settings, infrastructure code, containers, applications, everything.

For example: an S3 bucket policy might look fine on its own. But combine it with an overly permissive IAM role and a public subnet, and suddenly you have a security gap. CoGuard's contextual scanning can spot these cross-configuration problems that single-file scanners miss.

They're also using AI (funded by OpenAI's cybersecurity grant) to automatically create security policies for new technologies. This helps with a real problem: by the time traditional security scanners support new tools, those tools are already everywhere with possibly insecure defaults.

Build It Into Your Pipeline

Security scanning needs to happen automatically as part of your build process, not as something separate you remember to do sometimes:

# Example GitHub Actions workflow
name: Security Scan
on: [push, pull_request]
jobs:
  config-security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run configuration security scan
        run: |
          # Scan Terraform files
          tfsec .
          # Scan Kubernetes manifests
          kubesec scan k8s/*.yaml
          # Scan Dockerfiles
          hadolint Dockerfile

Failing the build when you find security problems means misconfigurations get caught before production. But you need to balance this with keeping your team productive—overly aggressive policies that flag too many false positives will just get ignored or worked around.

Watch What's Actually Running

Even with perfect pre-deployment scanning, configurations change over time. Someone makes a quick fix in the cloud console. An automation tool applies an update. A compromised account modifies settings.

Runtime monitoring catches this through:

• Cloud Security Posture Management (CSPM) tools that constantly scan your cloud environments
• Kubernetes security platforms that watch cluster configurations and pod settings
• Drift detection that alerts you when what's running doesn't match what you expected

Use Security Benchmarks

Don't write every security check from scratch. Use established standards:

• CIS Benchmarks for operating systems, cloud platforms, and applications
• NIST guidelines for government systems
• Industry standards like PCI-DSS for payments or HIPAA for healthcare

These represent what the security community agrees on for secure configurations, and they're updated regularly as new threats emerge.

Building Something That Actually Works

If you're serious about fixing misconfiguration problems, you need a systematic approach, not just ad-hoc scanning:

1. Write Down What "Secure" Means

Document what secure configuration actually looks like for your setup:

• Block everything by default on the network
• Give the minimum access needed, nothing more
• Encrypt data whether it's stored or moving around
• Set required security headers for web stuff
• Make sure you're logging what matters

These standards need to be specific enough that you can test them and enforce them automatically.

2. Automate the Scanning

Set up config security checks everywhere:

• Pre-commit hooks so developers catch issues on their laptops
  • Pull request checks that block merges when they find problems
  • Deployment gates that stop misconfigured stuff from reaching production
  • Regular scans of what's actually running to catch changes

  3. Fix the Important Stuff First

  
  Not every misconfiguration is equally dangerous. Focus on:
  • How easy is it to exploit? (Can anyone do it, or does it require specific knowledge?)
  • How bad would it be? (Does this expose everything, or just a small piece?)
  • Who can reach it? (Is it on the public internet, or buried inside your network?)
  • What's at risk? (Customer data? Financial records? Internal tools?)

This prevents remediation paralysis where teams are overwhelmed by hundreds of low-priority findings and miss critical issues.

4. Track How You're Doing

Measure your configuration security over time:

• What percentage of your stuff has misconfigurations?
• How long does it take to fix problems once you find them?
• Do you see the same mistakes happening repeatedly?
• How much of your infrastructure are you actually scanning?

Use these numbers to spot systemic problems and see if your security controls are actually working.

The People Side

Tools alone won't fix this. The human side matters just as much:

Train Your Team Properly

Developers and ops engineers need security training that's actually about configuration:

• What do common configs actually mean for security?
• What patterns create vulnerabilities?
• Which configs should never be exposed?
• What does "least privilege" actually mean in practice?

This needs to be practical and specific to what they're working with—not generic "here's what phishing is" training.

Learn From Mistakes Without Blame

When a misconfiguration causes a problem, focus on learning, not punishment. Good post-mortems:

• Figure out why the misconfiguration was possible in the first place
• Put in place controls to prevent the whole class of problems
• Share lessons with other teams who might make the same mistake

Blame culture makes people hide mistakes and not report issues. Learning culture makes security stronger.

Have Security People on Engineering Teams

Designate security champions within teams—people who are interested in security and can help their teammates. They:

• Review infrastructure code for security issues
• Push for security best practices
• Bridge the gap between security and engineering
• Provide security expertise without needing the central security team involved in everything

What's Next

Security Misconfiguration jumping to #2 on the OWASP Top 10 highlights a real tension: we're building increasingly complex systems with more and more configuration options, but we haven't figured out how to secure all those configs.

This isn't going away. If anything, it's getting worse as we adopt more cloud services, more container orchestration, more serverless functions, more microservices. The configuration surface just keeps expanding.

But there's also good news: this is an area where automation can really help. Unlike many security problems that require rewriting application logic, configuration security can be automated—both detection and sometimes even remediation. Tools like CoGuard that look at how configurations interact across your whole infrastructure represent real progress beyond simple file-by-file scanners.

The organizations that handle this well will be the ones that:

• Treat configuration like code, with the same care they give to application code
• Build security scanning into their development and deployment process
• Use tools that understand context across their entire infrastructure
• Make security knowledge part of every engineering team
• Actually measure and improve their configuration security over time

Misconfigurations moving to #2 isn't just a ranking change—it's acknowledging a fundamental challenge in how we build software now. We have the tools and knowledge to deal with it. The question is whether organizations will take it seriously enough, soon enough.

If you're running production infrastructure and haven't looked at your configurations recently, this is your sign. Those misconfigurations aren't just theoretical—they might be exactly how someone gets into your systems.

References

CoGuard. (2025). Misconfiguration causes 80% of all ransomware attacks. CoGuard. https://www.coguard.io/

OWASP Foundation. (2025). OWASP Top 10:2025. OWASP. https://owasp.org/Top10/2025/

OWASP Foundation. (2025). A02:2025 - Security Misconfiguration. OWASP Top 10. https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/