Security Misconfiguration (OWASP A02): The #1 Cloud Risk in 2026

Security Misconfiguration moved from #5 to #2 in the OWASP Top 10 2025 update. This isn't a statistical anomaly — it's a reflection of how cloud infrastructure has transformed the misconfiguration attack surface. A misconfigured S3 bucket, a default-credential admin panel, or a missing Content-Security-Policy header now exposes more organizations than SQL injection.

What Counts as Misconfiguration

The 2025 definition encompasses:

Missing Security Headers HTTP headers that defend against common client-side attacks. Missing or misconfigured headers are detectable in a single HTTP response.

Default Credentials Cloud-provisioned services (databases, admin panels, monitoring tools) often ship with documented default credentials. Teams that deploy quickly often don't change them.

Unnecessary Services and Features Debug mode enabled in production, directory listing on web servers, XML external entities (XXE) processing enabled by default, unnecessary HTTP methods.

Exposed Cloud Storage AWS S3 buckets, Azure Blob containers, or GCS buckets configured for public read (or worse, public write).

Verbose Error Messages Stack traces, framework versions, SQL query text returned in error responses. These are reconnaissance gifts to attackers.

Missing Encryption in Transit HTTP instead of HTTPS, outdated TLS versions (1.0/1.1), weak cipher suites.

HTTP Security Headers — The Lowest-Hanging Fruit

Every modern web application should serve these headers. They are configuration changes, not code changes. Detection is trivial — a single HTTP request reveals the entire header configuration.

Content-Security-Policy (CSP)

The most powerful XSS mitigation available. Without CSP, any injected script executes in the page context with full DOM access.

Content-Security-Policy: default-src 'self'; 
  script-src 'self' 'nonce-{random}'; 
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.yourapp.com;
  frame-ancestors 'none';

Starting a strict CSP on an existing application is challenging (many legacy scripts break). A pragmatic starting point:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations

Report-Only mode lets you measure violations before enforcing. Run it for 2 weeks, fix the violations, then switch to enforcing mode.

HTTP Strict Transport Security (HSTS)

Forces HTTPS for the duration of max-age. Eliminates SSL-stripping attacks.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

preload submits your domain to browser HSTS preload lists. After preloading, browsers refuse HTTP connections to your domain even on first visit (before receiving the header). Submit at hstspreload.org only after you've verified HTTPS works across all subdomains.

X-Frame-Options / frame-ancestors

Prevents your application from being embedded in iframes (clickjacking defense).

X-Frame-Options: DENY

Or via CSP:

Content-Security-Policy: frame-ancestors 'none';

CSP frame-ancestors supersedes X-Frame-Options in modern browsers. Include both for maximum compatibility.

X-Content-Type-Options

Prevents MIME-type sniffing:

X-Content-Type-Options: nosniff

Referrer-Policy

Controls what information is sent in the Referer header:

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Restricts browser features (camera, microphone, geolocation) to prevent feature abuse:

Permissions-Policy: geolocation=(), camera=(), microphone=()

Cloud Storage Misconfiguration

Exposed cloud storage is the misconfiguration that leads to the largest breach disclosures. The pattern is always the same: a storage bucket or container was created for a specific use case (file uploads, static assets, backup) and the access control was set too permissively.

AWS S3 Detection

# Check public accessibility
aws s3 ls s3://your-bucket --no-sign-request  # if this works, bucket is public

A publicly readable S3 bucket is bad. A publicly writable S3 bucket enables attackers to host malicious content on your infrastructure.

Detection at Scale

EASM tools scan for common naming patterns (company-backup, company-staging, company-assets) and test each for public accessibility. PentestCheck's EASM Engine includes S3, GCS, and Azure Blob public access checks.

Prevention

Enable the AWS S3 Block Public Access account-level setting:

{
  "BlockPublicAcls": true,
  "IgnorePublicAcls": true,
  "BlockPublicPolicy": true,
  "RestrictPublicBuckets": true
}

This is a one-click protection that prevents any bucket in your account from being made public, regardless of individual bucket settings.

Default Credentials — The 2-Minute Breach

Default credentials are a gift to attackers with patience and access to vendor documentation. Common targets discovered via EASM:

Any of these exposed to the internet is a critical finding. The mitigation hierarchy:

1. Remove from public internet access (require VPN)
2. Change default credentials immediately
3. Enable MFA where supported

Misconfiguration Hardening Checklist

Web Server

• Security headers configured (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
• Directory listing disabled
• Server version headers suppressed (Server: and X-Powered-By:)
• Debug mode disabled in production
• Error pages return generic messages (no stack traces)
• Unnecessary HTTP methods blocked (only GET/POST/PUT/PATCH/DELETE as needed)

TLS/HTTPS

• TLS 1.2+ only (TLS 1.0 and 1.1 disabled)
• Strong cipher suites only (no RC4, 3DES, NULL ciphers)
• Certificate expiry monitored (alert at 30 days)
• HSTS enabled with includeSubDomains

Cloud Infrastructure

• S3/GCS/Blob Block Public Access enabled
• No buckets with public write
• Default credentials changed on all services
• Admin panels not exposed to public internet
• Unused ports closed (firewall review)

Application

• Debug mode off
• XML external entity (XXE) processing disabled
• Security headers applied via framework middleware (not per-route)
• Dependency versions not exposed in responses

Running this checklist manually is a start. Automating it with continuous scanning is how you maintain compliance as infrastructure changes.

PentestCheck scans for 200+ misconfiguration patterns on every scan, including all security headers, TLS configuration, cloud storage exposure, and default credential paths.