Loading module...

Security Misconfiguration | Top 10 Dev Training

OWASP-02

Security Misconfiguration

Security misconfiguration is the most commonly seen issue, often resulting from insecure default configurations.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Security misconfiguration jumped from the number five spot in 2021 to number two in 2025. That's a significant move, and it tells you something important about where modern breaches are actually coming from.

When the OWASP Foundation analyzed applications for the 2025 list, they found over seven hundred nineteen thousand occurrences of misconfiguration-related weaknesses across the dataset. One hundred percent of tested applications had some form of misconfiguration. This isn't an exotic, novel risk class. It's the everyday gap between "we built something secure" and "we deployed it with the settings that ship by default."

So what does security misconfiguration actually look like? A few common patterns.

Default credentials left in place. An application server ships with a well-known admin account, and the team forgets to change the password. An attacker types the default credentials and is inside.

Unnecessary features enabled. Sample applications still running in production. Directory listing turned on, letting an attacker browse your file tree and download compiled code. Testing frameworks left installed on production servers. Every one of these is an entry point that didn't need to exist.

Overly informative error messages. When something goes wrong, the application returns a full stack trace to the user, revealing the framework version, the database type, the file paths, and sometimes even the query that failed. An attacker uses that information to find known vulnerabilities in exactly the versions you're running.

Open cloud storage. This one's been in headlines repeatedly. A cloud storage bucket gets created with default sharing permissions that allow public access. Someone uploads customer data, API keys, or internal documents, not realizing anyone on the Internet can read them.

And missing security headers. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options. These aren't magic, but they close off real attack vectors. Missing them means your site is more exposed than it needs to be.

Now, the most important thing to understand about 2025's ranking. Modern misconfiguration doesn't just live in web server settings. It lives in Terraform files, Kubernetes manifests, GitHub Actions workflows, container base images, and cloud IAM policies. Your infrastructure-as-code repositories are now production surfaces, and misconfigurations in them have the same blast radius as misconfigurations in the application itself. If you've been thinking "infrastructure is the ops team's problem," the 2025 ranking is telling you to stop.

CI/CD pipelines deserve a specific callout. A GitHub Actions workflow with overly broad secret access, or a deployment pipeline that trusts artifacts without verifying where they came from, is just as dangerous as a misconfigured database. Pipelines are production.

So how do you defend against this category? The patterns are mostly about discipline, not exotic tools.

First, make hardening repeatable. Development, QA, and production should be configured identically, with different credentials in each environment. Manual setup is where drift creeps in. Automate the process.

Second, minimize your platform. Remove features you don't use. Don't install documentation or samples. Close ports you don't need. Every component you don't have is a component that can't be misconfigured against you.

Third, scan infrastructure-as-code in CI. Tools like Checkov, tfsec, and Trivy read your Terraform, Kubernetes manifests, and container images, flagging configurations that don't match current security baselines. Run them on every pull request. This is the single highest-leverage change most teams can make.

Fourth, manage credentials properly. Short-lived, role-based credentials from identity federation. Never embed static keys or secrets in code, config files, or pipelines. If your deploy process includes any step that says "copy the access key," that's a bug.

And finally, verify annually if you can't verify automatically. Cloud permissions drift over time as people grant themselves temporary access and forget to revoke it. A yearly audit of who has access to what catches the accumulation before it becomes a breach.

Security misconfiguration is the number two risk for a reason. It's also one of the few categories where the fix is genuinely boring and genuinely effective. Automate your hardening, scan your infrastructure, and stop trusting defaults.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A02:2025 - Security Misconfiguration

Overview

Security misconfiguration occurs when a system, application, or cloud service is set up incorrectly from a security perspective, creating vulnerabilities.

Impact: 100% of applications tested were found to have some form of misconfiguration, with over 719,000 CWE occurrences. Moving up from #5, this is now the second most critical risk.

Common Vulnerabilities

Missing Security Hardening

Lack of appropriate security hardening across the application stack or improperly configured permissions on cloud services.

Unnecessary Features Enabled

Unnecessary features, ports, services, pages, accounts, testing frameworks, or privileges left enabled or installed.

Default Credentials

Default accounts and their passwords still enabled and unchanged, providing easy access to attackers.

Excessive Error Messages

Error handling that reveals stack traces or other overly informative error messages to users, exposing sensitive information.

Disabled Security Features

For upgraded systems, the latest security features are disabled or not configured securely due to excessive prioritization of backward compatibility.

Insecure Framework Settings

Security settings in application servers, frameworks (Struts, Spring, ASP.NET), libraries, and databases not set to secure values.

Missing Security Headers

The server does not send security headers or directives, or they are not set to secure values. Important browser-enforced protections that are commonly missing:

Clickjacking: without X-Frame-Options: DENY (or equivalent Content-Security-Policy: frame-ancestors 'none'), an attacker can embed your page in an invisible iframe on their own site and trick a logged-in user into clicking something they didn't intend (for example, a hidden "transfer funds" button positioned under a fake "Play video" button).
MIME-sniffing: without X-Content-Type-Options: nosniff, browsers may reinterpret a file's type based on its contents, turning an innocuous-looking upload into executable script.
TLS downgrade: without Strict-Transport-Security (HSTS), an active network attacker can strip HTTPS on the first visit and hold the user on HTTP.
Resource origin control: without a Content Security Policy (Content-Security-Policy), the browser has no declarative restriction on where scripts, styles, images, or frames may come from, which weakens the impact ceiling of an XSS or supply-chain injection.

XXE Vulnerabilities

Improper restriction of XML External Entity (XXE) references. When an XML parser is configured to resolve external entities, an attacker who controls any XML input can make the server read local files, make outbound network requests (SSRF), or in some parsers execute code.

Vulnerable pattern (Java, DocumentBuilderFactory defaults):

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder(); // external entities enabled by default
Document doc = db.parse(userSuppliedXmlStream);

Attacker submits XML containing:

<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<root>&xxe;</root>

On parsing, the server resolves the entity and returns the contents of /etc/passwd inside whatever response exposes the parsed node.

Mitigation: disable DTD processing and external entity resolution explicitly on every XML parser. In Java:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);

Prefer parsers and formats that don't support external entities at all (e.g., JSON) where feasible.

XXE is cross-listed under A05 Injection because the attack mechanism is injection-shaped. Untrusted XML input drives the parser to take unintended action. OWASP 2025 catalogs the root cause (a misconfigured XML parser with entity resolution left on) under Security Misconfiguration, so the primary treatment lives here.

Real-World Attack Scenarios

Scenario 1: Sample Applications Left in Production

The application server comes with sample applications not removed from production. These samples have known security flaws.

Attack: An attacker discovers the admin console is still accessible. Default accounts weren't changed, so the attacker logs in with default credentials and takes over the server.

Impact: Complete server compromise.

Scenario 2: Directory Listing Enabled

Directory listing is not disabled on the server.

Attack: An attacker discovers they can list directories, finds and downloads compiled Java classes, decompiles them, and reverse engineers the code. They discover a severe access control flaw.

Impact: Source code exposure and discovery of critical vulnerabilities.

Scenario 3: Detailed Error Messages

The application server's configuration allows detailed error messages with stack traces to be returned to users.

Attack: An attacker triggers errors to expose sensitive information, component versions, and underlying flaws that are known to be vulnerable.

Impact: Information disclosure leading to targeted attacks.

Scenario 4: Open Cloud Storage Permissions

A cloud service provider defaults to having sharing permissions open to the Internet.

Attack: An attacker discovers publicly accessible S3 buckets containing sensitive customer data, API keys, or internal documents.

Impact: Massive data breach, credential exposure.

How to Prevent

Repeatable Hardening Process

Implement a repeatable hardening process enabling fast and easy deployment of properly locked down environments:

Development, QA, and production environments should all be configured identically
Use different credentials in each environment
Automate the process to minimize effort and human error

Minimal Platform

Remove or do not install unused features and frameworks
Eliminate unnecessary features, components, documentation, or samples
Disable unnecessary ports and services

Configuration Management

Review and update configurations as part of patch management
Review cloud storage permissions (e.g., S3 bucket permissions)
Manually verify configurations annually at minimum if not automated

Segmented Architecture

Provide effective and secure separation between components or tenants using:

Segmentation
Containerization
Cloud security groups (ACLs)

Security Headers

Send security directives to clients, including:

Content-Security-Policy
X-Frame-Options
Strict-Transport-Security
X-Content-Type-Options

Automated Verification

Implement an automated process to verify the effectiveness of configurations and settings in all environments.

Centralized Error Handling

Proactively add central configuration to intercept excessive error messages as a backup.

Credential Management

Use identity federation, short-lived credentials, or role-based access mechanisms
Never embed static keys or secrets in code, configuration files, or pipelines

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0