A02 / Security Misconfiguration — OWASP Top 10 00 / 11
config mismatch detected
A02
OWASP Top 10 · 2025
Security
Misconfiguration
Everything looks fine — until one default, one copied config, one unchecked setting opens the door.
// microsoft power apps — 2021

In May 2021, a security researcher at UpGuard found that OData feeds on Microsoft Power Apps portals were returning sensitive data — including PII — to anyone who queried them. No authentication required. 38 million records across 47 organisations, including American Airlines, Ford, J.B. Hunt, state COVID-19 vaccination databases, and Microsoft's own payroll system. The data included Social Security numbers, vaccination appointments, employee IDs, and millions of email addresses. Nobody had attacked anything — the data was simply public by default.

May '21
Researcher finds open feeds
Jun '21
Reported to Microsoft
Jun '21
Microsoft: "by design"
Jul '21
Abuse report filed
Aug '21
Public disclosure
Aug '21
Defaults changed
↑ click any event to see what happened ↑
// classify the failure

The question: Microsoft said this was "by design." The documentation warned about it. Forty-seven organisations still got it wrong. What kind of security failure is this?

🐛 A software vulnerability
A bug in Microsoft's code that should have been patched.
⚙️ An insecure default
The platform defaulted to public access. Nobody changed it.
🔑 Missing authentication
The API endpoints had no login requirement.
📚 Poor documentation
Microsoft didn't warn users clearly enough.
// find the misconfiguration

Power Apps portal YAML configuration. One setting controls whether anonymous users can access table data. Click the line that opens the door.

portal-config.yaml
// attack walkthrough
step 1 of 4

Secure defaults. Then verify.

removed
added

The fix isn't complex code. It's a configuration change — and an automated check to make sure it stays changed. IaC should be treated like application code: linted, scanned, reviewed.

🎯 the one habit

Every new resource starts closed. Scan config in CI — tfsec, Checkov — and fail the build before misconfiguration reaches production.

Power Apps
Terraform (S3)
Kubernetes
portal-config.yaml
click the dot
why this works
// knowledge check
1 / 3

A cloud storage bucket is created by a Terraform pipeline copied from staging. The ACL defaults to public-read. What's the first line of defence?

A — Train developers to always check ACLs manually before deployment
B — Run an IaC security scanner (tfsec, Checkov) in CI that fails the build on public ACLs
C — Use a WAF in front of the bucket to filter unauthorised requests
// knowledge check
2 / 3

An application returns a full stack trace with internal file paths and database connection strings when an unhandled exception occurs. What A02 sub-category is this?

A — Missing encryption at rest
B — Default credentials left unchanged
C — Verbose error handling revealing sensitive system information
// knowledge check
3 / 3

In the 2025 OWASP Top 10, Security Misconfiguration moved from #5 to #2. What does OWASP cite as the primary driver?

A — The shift to highly configurable cloud-native software increases the surface area for misconfig
B — New XXE vulnerabilities were discovered in 2024
C — Misconfiguration was previously undercounted in OWASP's data methodology
// self-check complete

// the mental model

carry this into your next deploy

Security is not a feature you add. It's a default you start with and verify continuously. If the safe state requires someone to remember to change a setting — that setting will be wrong in production.

A02 · Security Misconfiguration
Scope in 2025
Cloud misconfig · default creds · verbose errors · XXE · missing headers
A02 rose from #5 to #2 in 2025. 16 mapped CWEs, 719K occurrences. The shift to cloud-native and IaC means more of an application's behaviour lives in configuration files, not code. XXE (CWE-611) is now included in this category. 100% of applications tested had some form of misconfiguration. For developers: your slice of A02 includes debug mode left on in production, verbose stack traces leaking to users, missing security headers (HSTS, CSP), overly permissive CORS, and insecure framework defaults. For DevOps: cloud storage exposure, IaC drift, default credentials, and unnecessary open ports. Both sides own this category.
First fix
Automate config scanning in CI — tfsec, Checkov, cfn-lint
Treat IaC like application code: lint it, scan it, review it. Run tfsec or Checkov in CI and fail the build on high-severity findings. This catches public buckets, default credentials, debug mode, and missing encryption before deployment — not after a breach.
Defence in depth
Identical environments · minimal platform · security headers · automated hardening
Dev, staging, and production must be configured identically (different credentials, same security posture). Remove unused features, ports, accounts, and sample apps. Send security headers (HSTS, CSP, X-Content-Type-Options). Automate hardening so a new environment starts secure by default.

// check your infrastructure today

Five things you can verify right now. None take more than ten minutes.

Cloud storage permissions
Are any buckets/blobs publicly accessible? Run: aws s3api get-bucket-acl
Default credentials
Admin panels, databases, message queues — any still using factory defaults?
Error handling in production
Does a 500 error reveal stack traces, file paths, or connection strings?
IaC security scanning
Is tfsec/Checkov running in CI? Does it fail the build on high severity?
Security headers
HSTS, CSP, X-Frame-Options, X-Content-Type-Options — all set?
0 / 5