Configuration weaknesses occur when software settings, files, or environment variables are set up in ways that introduce security vulnerabilities. This…
Configuration weaknesses occur when software settings, files, or environment variables are set up in ways that introduce security vulnerabilities. This includes insecure defaults, exposed debug modes, overly permissive file permissions, and misconfigured access controls. Unlike code flaws, configuration issues often go unnoticed because they don't appear in source code review — they live in deployment, environment setup, or administrative settings.
Configuration weaknesses arise when developers or administrators fail to harden settings after installation or deployment. Common patterns include shipping software with default credentials enabled, leaving debug modes active in production, storing sensitive data in world-readable files, or granting excessive permissions to application directories. The root cause is often a gap between development (where loose settings aid debugging) and production (where those same settings create attack surface). Configuration is frequently overlooked because it's not part of the codebase itself — it lives in config files, environment variables, web server settings, or database permissions.
Exposed configuration can lead to direct compromise. Debug modes may leak sensitive information like database credentials, API keys, or internal paths. Default credentials allow unauthorized access to admin panels or databases. Overly permissive file permissions let attackers read or modify application files, configuration, or user data. Misconfigured access controls can expose entire directories or APIs to the public. In aggregate, configuration weaknesses are among the most commonly exploited attack vectors because they require no code vulnerability — only a failure to lock down settings after deployment.
# app.py - Flask application with insecure defaults
from flask import Flask
app = Flask(__name__)
app.config['DEBUG'] = True # Debug mode enabled in production
app.config['SECRET_KEY'] = 'default-insecure-key' # Hardcoded default secret
app.config['SQLALCHEMY_ECHO'] = True # SQL queries logged to console
@app.route('/admin')
def admin():
return "Admin panel"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000) # Listening on all interfacesWhy it's vulnerable:
Debug mode exposes stack traces and internal state; the hardcoded secret key is the same across all installations; SQL echo logs queries (potentially with sensitive data); and binding to 0.0.0.0 makes the app accessible from any network interface.
# app.py - Flask application with secure defaults
import os
from flask import Flask
app = Flask(__name__)
app.config['DEBUG'] = False # Debug disabled in production
app.config['SECRET_KEY'] = os.environ.get('SECRET_KEY') # Load from environment
if not app.config['SECRET_KEY']:
raise ValueError("SECRET_KEY environment variable not set")
app.config['SQLALCHEMY_ECHO'] = False # SQL logging disabled
@app.route('/admin')
def admin():
return "Admin panel"
if __name__ == '__main__':
app.run(host='127.0.0.1', port=5000) # Listen only on localhost<?php
// config.php - WordPress-style configuration with weak settings
define('DB_USER', 'admin');
define('DB_PASSWORD', 'password123'); // Default/weak password
define('WP_DEBUG', true); // Debug mode enabled
define('WP_DEBUG_LOG', '/var/www/html/debug.log'); // World-readable log
// Permissions on wp-config.php: 644 (world-readable)
// File permissions on uploads/: 777 (world-writable)
?>Why it's vulnerable:
Hardcoded default credentials are easy to guess; debug mode logs sensitive information to a world-readable file; and overly permissive file permissions allow attackers to read or modify application files.
<?php
// config.php - Secure configuration
define('DB_USER', getenv('DB_USER'));
define('DB_PASSWORD', getenv('DB_PASSWORD'));
if (!defined('DB_USER') || !defined('DB_PASSWORD')) {
die('Database credentials not configured via environment variables.');
}
define('WP_DEBUG', false); // Debug disabled in production
define('WP_DEBUG_LOG', '/var/log/app/debug.log'); // Outside web root
// File permissions set via deployment:
// wp-config.php: 600 (owner read/write only)
// uploads/: 755 (owner read/write/execute, others read/execute)
?>Check your application logs and error pages for exposed paths, database connection strings, or API keys. Review file permissions on your application directory and configuration files — if config files are world-readable or application directories are world-writable, configuration is misconfigured. Look for debug output, stack traces, or SQL queries visible in browser responses or public log files. Verify that default credentials have been changed for all services and that debug modes are disabled in production.
