OWASP Top 10:2021 — A05: Security Misconfiguration

Welcome to Part 5 of this OWASP Top 10 series. So far, we’ve covered insecure code, weak design, and architectural flaws. Now it’s time to talk about something a bit less glamorous — but incredibly dangerous: Security Misconfiguration.

This risk isn’t about bad logic or broken code. It’s about systems that are working as configured — but configured insecurely.

From forgotten admin consoles to open S3 buckets, misconfiguration is the low-hanging fruit attackers love.

Full series:

1. A01: Broken Access Control
2. A02: Cryptographic Failures
3. A03: Injection Attacks
4. A04: Insecure Design
5. A05: Security Misconfiguration (you are here)
6. A06: Vulnerable and Outdated Components
7. A07: Identification and Authentication Failures
8. A08: Software and Data Integrity Failures
9. A09: Security Logging and Monitoring Failures
10. A10: Server-Side Request Forgery (SSRF)

What is Security Misconfiguration?

Security misconfiguration happens when security settings are missing, weak, or left at unsafe defaults — in the app, the server, the cloud infrastructure, or even your CI/CD pipeline.

Common examples:

• Debug mode enabled in production
• Directory listings enabled on a web server
• Default admin credentials still active
• Unpatched software with known vulnerabilities
• Overly permissive CORS policies
• Public cloud storage (e.g., AWS S3) open to anyone

Why Does This Happen?

There are a few reasons misconfiguration is everywhere:

• Default settings aren’t secure — and devs forget to change them.
• Infrastructure is complex — especially with containers, Kubernetes, and cloud.
• Dev and prod environments drift apart, causing inconsistent behavior.
• “If it works, ship it” culture pushes security reviews aside.

In other words: convenience wins, security loses.

How Attackers Exploit Misconfigurations

Attackers often start by scanning the internet for weak spots — and misconfigured systems light up like a Christmas tree.

Example 1: Exposed Admin Interfaces

An admin panel is accessible at /admin, with no IP restrictions or authentication. An attacker finds it via a crawler or /robots.txt, and gains full access.

Example 2: Open Cloud Storage

An S3 bucket meant to store internal PDFs is publicly accessible. A competitor (or anyone) finds the bucket name and downloads confidential documents.

Example 3: Overly Permissive CORS

A web app sets Access-Control-Allow-Origin: *, allowing any site to read responses — even with sensitive user data like tokens.

Example 4: Debug Mode Left On

The app is deployed with debug mode enabled. When an exception is thrown, the full stack trace — including file paths, API keys, and framework versions — is printed to users.

How Engineers Can Prevent It

This is where operational discipline and a strong DevSecOps culture really shine.

1. Disable Unnecessary Features
   • Turn off debug mode, verbose error messages, and directory listings in production.
   • Remove or restrict access to admin panels and test endpoints.
2. Harden Configurations
   • Use secure headers (X-Content-Type-Options, Strict-Transport-Security, etc.).
   • Validate CORS settings — avoid wildcards unless you’re 100% sure.
3. Lock Down Cloud Resources
   • Use private ACLs for buckets, blobs, and storage containers.
   • Enable logging and access controls for cloud assets.
4. Patch and Update Regularly
   • Outdated components are a misconfiguration risk too. Apply patches to OS, libraries, containers, and infrastructure.
5. Use Infrastructure as Code (IaC)
   • Define configs in code (e.g., Terraform, CloudFormation) and review them like any other code.
   • Run security scanners on IaC to catch misconfigured resources before deployment.
6. Automate Configuration Checks
   • Tools like AWS Config, kube-bench, tfsec, and CIS benchmark scanners help spot drift and bad defaults.

Real-World Example: The Forgotten Dev Endpoint

A dev team sets up a /healthcheck-debug endpoint for internal testing. It returns app status, DB connection info, environment variables — everything.

It was supposed to be disabled before launch.

It wasn’t.

An attacker finds it and learns everything about the system architecture in seconds — laying the groundwork for future attacks.

Final Thoughts

Security misconfigurations are like unlocked doors in a high-rise building. The code might be fine, the walls strong, but if the back door is wide open — you’re still vulnerable.

It’s not just about writing secure software. It’s about deploying it securely, too.

Next up: A06: Vulnerable and Outdated Components → We’ll explore how third-party libraries and packages can quietly introduce major risks — even if your own code is airtight.