OWASP Top 10 A02 Guide: Security Misconfiguration (2025): Hardening Defaults Across the Stack

Security misconfiguration affected every application OWASP tested for the 2025 edition, and it has climbed from fifth place in 2021 to A02:2025 Security Misconfiguration. The category covers insecure settings anywhere in the stack: default accounts left enabled, debug pages and stack traces in production, missing security headers, open cloud storage, permissive XML parsers and cross-domain policies. OWASP links the rise to the growing amount of highly configurable software. This guide goes beyond the OWASP Top 10 overview to explain what A02 contains, the requirements that close it, a phased hardening programme, how to test and evidence it, and the machine credentials that misconfiguration so often exposes. It is for application security engineers, platform and DevOps teams, cloud engineers and testers.

Key takeaways

• Second place and universal. OWASP found some form of misconfiguration in every application tested, with 719,084 occurrences across 16 mapped CWEs and a maximum incidence rate of 27.70%.
• Hardening must be repeatable. OWASP's first prevention point is an automated hardening process that rebuilds every environment the same way, with different credentials per environment.
• Configuration is code. Settings that live in templates, images and infrastructure as code can be scanned, reviewed and drift-checked; settings changed by hand cannot.
• Defaults are the enemy. Default credentials, sample apps, verbose errors and open sharing defaults appear in OWASP's scenarios and in the NSA and CISA list of the most common misconfigurations.
• Replace embedded secrets with identity. The 2025 text tells teams to use identity federation, short-lived credentials or platform role-based access instead of static secrets in configuration.

What it is and who it applies to

OWASP defines security misconfiguration as a system, application or cloud service set up incorrectly from a security perspective. It is a property of the deployed system rather than of the source code, which is why it affects bought, open source and in-house software alike. In the 2025 data A02 has an average incidence rate of 3.00%, average coverage of 52.35%, an average weighted exploit score of 7.96 and an average weighted impact of 3.97. Only 1,375 CVEs map to it, which fits a category made up largely of local deployment choices rather than product flaws. OWASP highlights CWE-16 (Configuration) and CWE-611 (Improper Restriction of XML External Entity Reference) as notable.

An application is likely vulnerable if any of the following is true:

• Missing hardening: any part of the stack is not hardened, or cloud service permissions are wrong.
• Unneeded features: ports, services, pages, accounts, test frameworks or privileges are enabled without need.
• Default accounts: default accounts and passwords are still enabled and unchanged.
• Verbose errors: error handling is not centralised, so stack traces or detailed messages reach users.
• Upgrades left insecure: new security features are disabled or misconfigured after an upgrade, or backward compatibility wins over security.
• Insecure settings: servers, frameworks, libraries and databases are not set to secure values.
• Missing headers: security headers or directives are absent or set insecurely.

It applies to web servers, application frameworks, API gateways, container platforms, databases, identity providers, SaaS tenants and public cloud accounts. Platform and operations teams usually own more of A02 than developers do.

Structure and key requirements

The table maps the CWEs OWASP lists for A02 to what they look like in practice and the setting that fixes them.

OWASP's prevention list gives eight requirements:

1. Repeatable, automated hardening so new environments are locked down quickly, with development, QA and production configured identically but using different credentials.
2. A minimal platform without unused features, components, documentation and samples.
3. Configuration review as part of patch management, including cloud storage permissions.
4. Segmented architecture using segmentation, containers or cloud security groups and ACLs.
5. Security headers sent to clients.
6. Automated verification of configuration in all environments, or at least an annual manual check where automation is impossible.
7. A central error handler as a backstop against excessive error messages.
8. Identity in place of static secrets: identity federation, short-lived credentials or platform role-based access.

The ASVS 5.0 requirements behind A02

See the Security Headers Guide and the OWASP ASVS Guide.

Identity and NHI requirements

Misconfiguration is one of the main ways machine credentials leak, and default or shared accounts are one of the main misconfigurations. The NSA and CISA advisory AA23-278A lists default configurations including default credentials, improper separation of user and administrator privilege, and poor credential hygiene among the ten most common misconfigurations its red and blue teams found.

• Default and test accounts: disable or rename vendor defaults and remove test administrators before go-live. In the McHire default password flaw a test admin account unused since 2019 still accepted 123456 with no MFA.
• Secrets in configuration: passwords in config files (CWE-13) and environment variables exposed by debug pages (CWE-526) become usable credentials. Move them to a vault or replace them with workload identity. See the Secrets Management Guide and the OWASP NHI Top 10 NHI6 Insecure Cloud Deployment Configurations Guide.
• Source control metadata: deploying whole project folders publishes .git, and clone URLs with embedded tokens in .git/config hand over working credentials, as the misconfigured Git servers research showed.
• Separate credentials per environment: OWASP requires identical configuration but different credentials in each environment, so a leaked development key does not open production. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.
• Database and BaaS policies: backend-as-a-service keys shipped to browsers depend entirely on server-side policy. The Moltbook database exposure came from row level security never being configured.
• Cloud metadata endpoints: on AWS, instances accept IMDSv1 and IMDSv2 by default; set token usage to required so metadata, including role credentials, needs a session token.

Implementation steps

1. Inventory what you run. List every platform component per application: OS image, web server, runtime, framework, database, gateway, cloud services and SaaS tenants. You cannot harden what you have not listed.
2. Pick a baseline per component. Use CIS Benchmarks or vendor hardening guides as the starting point and record each accepted deviation with a reason and owner.
3. Encode the baseline. Express it in golden images, container base images, infrastructure as code modules and framework configuration committed to source control, so every environment is built from the same definition. See the Infrastructure as Code Security Guide.
4. Add policy checks in the pipeline. Scan IaC templates and container images before deployment and block known-bad settings such as public storage, open security groups, debug flags and missing headers. Start in warn-only mode for two to four weeks, tune false positives, then block.
5. Close cloud defaults. On AWS turn on all four S3 Block Public Access settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) at account level, or at organisation level where all four apply together, and require IMDSv2. Apply the equivalent controls on other providers. See the Cloud Misconfiguration Guide.
6. Harden the application layer. Centralise error handling, disable debug and TRACE, remove sample apps and admin consoles from internet exposure, set cookie attributes and security headers, and disable XML external entities.
7. Monitor for drift. Continuously compare running configuration with the baseline using posture management for cloud and SaaS and configuration compliance scans for hosts. Treat drift as a ticket with an owner and a due date.
8. Roll out by ring. Apply new baselines to a pilot environment first, then non-production, then production, with the previous image or template version kept so you can roll back quickly if a setting breaks a dependency.
9. Review on every upgrade. Tie configuration review to patch management, as OWASP requires, because upgrades introduce new features that may ship disabled or insecure.

Choosing a verification approach

A small organisation with one cloud account can get far with provider-native configuration rules, IaC scanning and a DAST scan in the pipeline. Large estates need posture management across accounts and tenants, central baselines and an exception process, because drift outpaces manual review.

Evidence and assessment

The OWASP Web Security Testing Guide v4.2 groups configuration tests in section 4.2, Configuration and Deployment Management Testing:

Assessors typically ask for: the approved baseline per platform and the list of exceptions; IaC scan and image scan results from CI; posture management reports showing current findings and age; DAST results for headers and error handling; evidence that default accounts are disabled; and change records tying configuration reviews to patch cycles.

Detection and metrics

• Monitor: cloud audit logs for storage policy and ACL changes that grant public access, security group changes opening management ports, logins to default or test accounts, and requests for /.git/, backup extensions and admin paths in web logs.
• Metric 1: percentage of assets built from an approved, version-controlled baseline.
• Metric 2: open critical misconfiguration findings and their median age.
• Metric 3: mean time from drift detection to remediation.
• Metric 4: percentage of deployments blocked or warned by pipeline policy checks, trending down as baselines mature.
• Metric 5: percentage of internet-facing apps passing header and error-handling checks.

Mapping to other frameworks

See the OWASP API Top 10 API8 Security Misconfiguration Guide and the CIS Controls Guide.

Common pitfalls

• Hardening once, by hand: a well-configured server is rebuilt from an old image, or a console change is never written back to IaC, and the fix silently disappears.
• Debug left on: stack traces and framework debug pages reveal versions, paths and environment variables, which is OWASP's third example scenario.
• Trusting cloud defaults: OWASP's fourth scenario is a provider's default sharing permissions exposing stored data; AWS states that users can still change policies to allow public access unless Block Public Access is on.
• Publishing the build folder: deploying with .git or backups inside the web root, as in the misconfigured Git servers case, or blocking it on one hostname but not another.
• Same credentials everywhere: a shared secret across development and production means any lower-environment leak is a production compromise.
• Exceptions without expiry: deviations from the baseline are approved once and never revisited, so they accumulate into the real configuration.

Practitioner checklist

• Maintain an inventory of every platform component and SaaS tenant behind each application.
• Adopt a documented baseline per component (CIS Benchmark or vendor guide) with owned, time-limited exceptions.
• Build every environment from version-controlled images and IaC, with different credentials per environment.
• Scan IaC and images in CI, moving from warn to block once false positives are tuned.
• Turn on S3 Block Public Access (or the provider equivalent) and require IMDSv2 on cloud workloads.
• Disable default and test accounts, debug modes, TRACE, directory listing and XML external entities in production.
• Send HSTS, Content-Security-Policy and X-Content-Type-Options headers and set secure cookie attributes.
• Replace secrets in configuration files and environment variables with a vault or workload identity.
• Run continuous drift detection and review configuration on every upgrade and patch cycle.

Standards and references

• OWASP: A02:2025 Security Misconfiguration
• OWASP: Top 10:2025 Introduction
• OWASP: Web Security Testing Guide, Configuration and Deployment Management Testing
• OWASP: Application Security Verification Standard
• CISA and NSA: Top Ten Cybersecurity Misconfigurations (AA23-278A)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• AWS: Blocking public access to your Amazon S3 storage

Related NHI Mgmt Group resources: OWASP Top 10 Guide · OWASP Top 10 A01 Guide · OWASP Top 10 A03 Guide · Cloud Misconfiguration Guide · Infrastructure as Code Security Guide