A05 — Security Misconfiguration. It’s been sitting on the OWASP Top 10 list forever, and somehow it keeps climbing. It knocked A06 Vulnerable and Outdated Components off its throne because the industry collectively decided that default passwords and exposed debug endpoints are totally fine in production. They are not.
What makes this category so frustrating is that it has nothing to do with clever zero-days or advanced threat actors. Most of the time it’s an engineer who forgot to flip one flag, left one header out, or deployed a Helm chart with the demo values still in place. The attacker’s job is embarrassingly easy.
This article covers the configurations that are actively exploited right now, in 2026 — the ones turning up in real penetration test reports, bug bounties, and post-mortems. Not theoretical, not academic.
Why "It Works" Is Not the Same as "It’s Secure"
Every default configuration is optimized for convenience, not security. Frameworks boot in debug mode. Cloud services default to public access. Container runtimes run as root. The path of least resistance during development is the path straight into your production environment if you’re not deliberate about hardening.
The core problem is that misconfiguration is invisible at runtime. The app works perfectly — requests succeed, data flows, users are happy. Nobody notices until someone posts your S3 bucket contents on a dark web forum.
1. Default Credentials Left Untouched
Still the #1 quickest win for attackers in 2026. Shodan shows tens of thousands of live Grafana, Jenkins, MinIO, RabbitMQ, and Elasticsearch instances answering on their default ports with admin/admin or no credentials at all.
The pattern is always the same: a developer spins up a service for local testing, it gets containerized, the compose file gets committed, staging copies it, production mirrors staging. Nobody changes the passwords because "we’ll do that before go-live."
Production-ready solution: enforce credential injection from secrets at startup — never bake passwords into compose files or Helm values:
# docker-compose.yml
services:
grafana:
image: grafana/grafana:latest
environment:
# Pull from Docker secrets or a secrets manager
GF_SECURITY_ADMIN_PASSWORD__FILE: /run/secrets/grafana_password
secrets:
- grafana_password
secrets:
grafana_password:
external: true
And block the default ports from ever reaching the public internet. If 9000 (MinIO), 5601 (Kibana), or 8161 (ActiveMQ) are reachable from 0.0.0.0 in your firewall rules, you have a problem regardless of credentials.
Gotcha: Docker’s port publishing (-p 9000:9000) binds to all interfaces by default, bypassing ufw and iptables rules. Use 127.0.0.1:9000:9000 in compose files for admin services. Always.
2. Missing or Weak HTTP Security Headers
This one is boring, which is why it gets skipped. But missing security headers are trivially exploitable and show up in every serious security audit.
The minimum viable set for any web application in 2026:
# /etc/nginx/snippets/security-headers.conf
# Prevents your page from being framed — stops clickjacking
add_header X-Frame-Options "SAMEORIGIN" always;
# Force HTTPS for 2 years, including subdomains
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
# Stops MIME-type sniffing attacks
add_header X-Content-Type-Options "nosniff" always;
# Controls what info gets sent in Referer header
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Disable FLoC and lock down browser features
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
# The big one — enforce where resources can load from
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';" always;
# Remove the server fingerprint
server_tokens off;
Include this snippet in your server {} blocks. Then verify with securityheaders.com — it’ll grade you and explain every gap.
Gotcha: Content-Security-Policy is the header that breaks things. Start in report-only mode (Content-Security-Policy-Report-Only) with a reporting endpoint so you can collect violations before enforcing:
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report-endpoint;" always;
3. CORS Configured for "Development Convenience"
Few misconfigurations cause as much damage as a permissive CORS policy that somehow made it to production. The classic one:
# The lazy developer's nightmare
app.add_middleware(
CORSMiddleware,
allow_origins=["*"],
allow_credentials=True, # This is the killer combination
allow_methods=["*"],
allow_headers=["*"],
)
allow_origins=["*"] combined with allow_credentials=True is actually rejected by browsers per spec — but developers often work around it by echoing back the Origin header dynamically:
# Even worse — dynamic origin reflection
origin = request.headers.get("Origin")
response.headers["Access-Control-Allow-Origin"] = origin # Trusts any origin
response.headers["Access-Control-Allow-Credentials"] = "true"
Now any attacker’s site can make authenticated requests to your API using the victim’s session cookies.
Production-ready solution: maintain an explicit allowlist:
ALLOWED_ORIGINS = [
"https://app.yourdomain.com",
"https://admin.yourdomain.com",
]
app.add_middleware(
CORSMiddleware,
allow_origins=ALLOWED_ORIGINS,
allow_credentials=True,
allow_methods=["GET", "POST", "PUT", "DELETE"],
allow_headers=["Authorization", "Content-Type"],
)
Gotcha: Don’t regex-match origins like r"https://.*yourdomain\.com" unless you’re absolutely sure about the subdomain surface. https://evil.com?x=yourdomain.com won’t match, but https://notyourdomain.com trivially defeats naive suffix checks.
4. Verbose Error Messages and Stack Traces in Production
Leaking a Python traceback, a Java stack trace, or a SQL error to the end user hands an attacker a roadmap. They learn your framework, your ORM, your database type, your file structure, and often the exact query that failed.
# What an attacker sees instead of a generic 500:
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError)
FATAL: password authentication failed for user "app_user"
[SQL: SELECT * FROM users WHERE email = '[email protected]']
(Background on this error at: https://sqlalche.me/e/14/e3q8)
This one line tells them: PostgreSQL, SQLAlchemy, psycopg2, the table name, the column name, and that auth is email-based.
Production-ready solution: separate error handling into two paths:
import logging
import traceback
from fastapi import Request
from fastapi.responses import JSONResponse
logger = logging.getLogger(__name__)
@app.exception_handler(Exception)
async def generic_exception_handler(request: Request, exc: Exception):
# Full details go to your logging system, never to the client
logger.error(
"Unhandled exception",
exc_info=True,
extra={"path": request.url.path, "method": request.method}
)
# The client gets nothing useful to an attacker
return JSONResponse(
status_code=500,
content={"detail": "An internal error occurred. Reference ID logged."}
)
Ship structured logs to a centralized system (Loki, Elastic, Datadog — your call) and never let raw exceptions reach HTTP responses.
5. Cloud Storage Buckets Exposed to the World
S3, GCS, Azure Blob — they all default to some form of public access unless you explicitly fight against that. The number of exposed buckets containing backups, user uploads, internal configs, and private keys is still staggering in 2026.
The AWS fix is two-pronged: account-level block and bucket-level block:
# Block public access at the account level — do this first for every AWS account
aws s3control put-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text) \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
// Bucket policy that explicitly denies public GetObject
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyPublicRead",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
Use pre-signed URLs for any legitimate temporary access to private objects — don’t make buckets public just because your frontend needs to display user avatars.
Gotcha: Terraform’s aws_s3_bucket resource used to set ACLs inline. In newer versions, aws_s3_bucket_public_access_block is a separate resource and it’s easy to forget. Add a policy check in your CI pipeline:
# Simple check in CI — fails if any bucket has public access enabled
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
xargs -I{} aws s3api get-public-access-block --bucket {} 2>/dev/null | \
grep -E '"BlockPublicAcls": false|"BlockPublicPolicy": false' && \
echo "PUBLIC BUCKET FOUND — FAILING BUILD" && exit 1
6. Kubernetes RBAC: The "It Works" Disaster
Kubernetes RBAC is one of those things people set up once and never revisit. The quick-start tutorials are littered with ClusterRole bindings to ServiceAccounts that have no business touching anything beyond their own namespace.
The two most dangerous patterns:
Pattern A: Wildcard permissions
# This is fine for local dev, catastrophic in prod
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Pattern B: Binding the default service account
Pods use the default service account in their namespace by default. If you bind any ClusterRole to it, every pod in that namespace inherits those permissions — including compromised ones.
Production-ready solution: follow least privilege strictly:
# Create a dedicated service account per workload
apiVersion: v1
kind: ServiceAccount
metadata:
name: payment-service
namespace: production
---
# Grant only what this workload actually needs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: payment-service-role
namespace: production
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["payment-api-key"] # Specific secret, not all secrets
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: payment-service-binding
namespace: production
subjects:
- kind: ServiceAccount
name: payment-service
namespace: production
roleRef:
kind: Role
name: payment-service-role
apiGroup: rbac.authorization.k8s.io
Also disable auto-mounting of service account tokens for workloads that don’t call the Kubernetes API:
spec:
automountServiceAccountToken: false
Gotcha: kubectl auth can-i --list --as=system:serviceaccount:production:default — run this against your namespaces. You’ll be surprised what the default account can do.
7. Debug Mode and Development Features Enabled in Production
This sounds too obvious to still be happening. It is still happening. Django’s DEBUG = True in prod. Spring Boot Actuator with all endpoints exposed. Node.js apps with --inspect active. PHP with display_errors = On.
Django’s debug mode exposes every URL pattern, all settings (including SECRET_KEY and database credentials), and full stack traces. One misconfigured environment variable away from a complete application disclosure.
# settings/production.py — non-negotiable
DEBUG = False
ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"]
# Never let this come from a default or committed value
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]
Spring Boot Actuator is particularly nasty because it ships with /actuator/env (dumps all environment variables), /actuator/heapdump (heap memory dump, potentially containing secrets), and /actuator/logfile all exposed by default since Boot 2.x.
# application-production.yml
management:
endpoints:
web:
exposure:
# Expose only health and metrics — lock down everything else
include: "health,metrics,prometheus"
endpoint:
health:
show-details: never
Then put the actuator behind a separate port and firewall it off from public access entirely.
8. Container Images Running as Root
The majority of official Docker images still run their process as root inside the container. If your application has a vulnerability that allows command execution, the attacker has root inside the container — and depending on your Docker socket setup and kernel version, that can mean root on the host.
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# Create a non-root user and switch to it before the entrypoint
RUN groupadd -r appuser && useradd -r -g appuser -u 1001 appuser
RUN chown -R appuser:appuser /app
USER appuser
EXPOSE 8000
CMD ["gunicorn", "app:application", "--bind", "0.0.0.0:8000"]
Combine this with a read-only root filesystem:
# docker-compose.yml
services:
api:
image: your-api:latest
read_only: true
tmpfs:
- /tmp # Writable temp space if the app needs it
security_opt:
- no-new-privileges:true # Prevents privilege escalation via setuid
cap_drop:
- ALL # Drop all Linux capabilities
cap_add:
- NET_BIND_SERVICE # Add back only what's actually needed
Gotcha: The --privileged flag completely defeats every container security boundary. Grep your compose files and Helm charts for it:
grep -r "privileged" ./k8s/ ./docker-compose*.yml
If it’s there, it needs a very compelling reason to stay.
9. TLS Misconfiguration: Old Protocols and Weak Ciphers
TLS 1.0 and 1.1 were deprecated years ago, yet you still find them enabled on corporate infrastructure, internal tools, and the occasional payment system. SSLv3 is still detectable in some environments. This isn’t theoretical — POODLE and BEAST are well-understood attacks with working exploits.
Minimal Nginx TLS config for 2026:
# /etc/nginx/snippets/ssl-params.conf
ssl_protocols TLSv1.2 TLSv1.3;
# Prefer TLS 1.3 ciphers when available, explicit fallback for 1.2
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off; # Let the client pick from TLS 1.3 suite
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off; # Forward secrecy
# OCSP stapling — reduces connection time and leaks less info to CA
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
Verify with: nmap --script ssl-enum-ciphers -p 443 yourdomain.com or testssl.sh. Aim for at least an A on SSL Labs.
Automate the Detection
You can’t manually audit every service every time someone pushes a new container tag. Wire these into your CI/CD:
# In your CI pipeline (GitHub Actions, GitLab CI, etc.)
# Scan container images for misconfigurations before they ship
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image --severity HIGH,CRITICAL your-app:latest
# Scan Kubernetes manifests
docker run --rm -v $(pwd):/manifests \
aquasec/trivy config /manifests/k8s/
# Check running cluster configs
kube-bench run --targets master,node --json | \
jq '.Controls[].tests[].results[] | select(.status == "FAIL")'
Add Checkov for Terraform and Helm chart scanning. Set it as a required check on pull requests — not a "nice to have" advisory step.
The Uncomfortable Truth
Every single item in this article is free to fix. No budget approval required, no vendor purchase order, no lengthy compliance project. It’s configuration. It’s a flag, a header, a policy block, a Dockerfile line.
The reason these misconfigurations persist isn’t ignorance — most developers know better. It’s the pressure to ship, the assumption that "security will review it later," and the fact that nothing breaks visibly when you get it wrong. Until something does.
Run docker run --rm -p 4000:4000 owasp/juice-shop locally and spend an hour trying to exploit a misconfigured application. It’s humbling and it makes the theory concrete fast.
Security misconfiguration is the category where you have the most leverage with the least effort. No reason not to start today.