This misconfiguration occurs when an application is deployed to a production environment with debugging features still enabled. Debug modes often provide verbose error messages (like stack traces, see CWE-209), may disable security features (like caching or certain headers), might use default credentials, or could expose internal application state. While extremely useful during development, these features provide attackers with valuable information and potentially bypass security controls in a live environment. 🐞➡️🌍
Deploying with debug mode enabled significantly increases the attack surface:
Information Disclosure: Leaks detailed error messages, stack traces, configuration settings (potentially including secrets), file paths, and framework versions, aiding attackers in reconnaissance.
Security Feature Bypass: Debug modes might disable crucial security headers (like X-Frame-Options), CSRF protection, or input validation optimizations, making other attacks easier.
Performance Degradation: Debug modes often consume more resources and perform slower than optimized production builds.
Potential Credential Exposure: Some debug tools or configurations might inadvertently expose default or development credentials.
Reference Details
CWE ID:CWE-11 (Specific to ASP.NET Debug Binaries, but represents the general issue)
Related CWEs: CWE-209 (Sensitive Errors), CWE-526 (Env Vars), CWE-16 (General Configuration)
OWASP Top 10 (2021): A05:2021 - Security Misconfiguration
Severity: High
This is a deployment and configuration issue common across many frameworks. The key is to ensure the application runs using its production configuration profile, where debugging is disabled and optimizations are enabled.Remediation:
Use Production Build/Configuration: Ensure build processes and deployment scripts explicitly use the production environment settings.
Disable Debug Flags: Set framework-specific debug flags (DEBUG, ASPNETCORE_ENVIRONMENT, FLASK_DEBUG, APP_DEBUG, etc.) to their production values (False, Production, 0).
Configure Error Handling: Implement generic error pages for production (see CWE-209).
Review Configuration Files: Double-check configuration files (web.config, settings.py, application.properties, .env) to ensure no debug settings or development credentials remain.
# DANGEROUS: Running Flask in debug mode on production.export FLASK_ENV=development # Also implies debug in older Flaskexport FLASK_DEBUG=1flask run --host=0.0.0.0
# app.py (Alternative dangerous way if using app.run directly)if __name__ == '__main__': # DANGEROUS: Never run with debug=True in production. app.run(debug=True, host='0.0.0.0')
Django: Set DEBUG = False in production settings.py. Use environment variables or separate settings files (e.g., production_settings.py) to manage this. Configure LOGGING and custom error pages (500.html, 404.html).
Flask: Set FLASK_ENV=production and ensure FLASK_DEBUG=0 (or unset) in the production environment. Configure custom error handlers using @app.errorhandler. Use a production WSGI server (Gunicorn, uWSGI).
# settings.py (Django Production - Secure)import os# SECURE: Default to False, override with env var only if needed (e.g., staging)DEBUG = os.environ.get('DJANGO_DEBUG', 'False') == 'True'# Ensure DEBUG is absolutely False in true production environments!ALLOWED_HOSTS = ['yourdomain.com']# ... configure LOGGING, custom error templates ...
# Production Environment for Flask (Secure)export FLASK_ENV=production# FLASK_DEBUG is implicitly 0 or unset# Run with Gunicorn: gunicorn myapp:app
# application.properties (Production)# DANGEROUS: Shows full stack trace in browser/API response.server.error.include-stacktrace=always# DANGEROUS: Running with development profile active in prod.# spring.profiles.active=development
Vulnerable Scenario 2: Verbose Logging Levels in Production
# application.properties / logback.xml / log4j2.xml (Production)# DANGEROUS: Logging excessive DEBUG or TRACE level info in production# might leak sensitive operational data or performance details.logging.level.org.springframework=DEBUGlogging.level.com.myapp=TRACE
# application-production.properties (Secure)# SECURE: Activate this profile via env var SPRING_PROFILES_ACTIVE=production# SECURE: Never include stack traces in responses.server.error.include-stacktrace=never# SECURE: Disable the default Spring error page.server.error.whitelabel.enabled=false# SECURE: Set appropriate logging levels for production.logging.level.root=INFOlogging.level.org.springframework=WARNlogging.level.com.myapp=INFO # Adjust as needed
Check the active Spring profile (/actuator/env if exposed, or server logs). Trigger errors and verify generic error pages are shown without stack traces. Review production logging configuration files and sample log output for appropriate log levels and absence of overly verbose or sensitive debug information.
Controlled by the ASPNETCORE_ENVIRONMENT environment variable and the <compilation debug="true/false"> setting in web.config (older ASP.NET) or build configurations (Debug vs. Release in ASP.NET Core).
The production server has the ASPNETCORE_ENVIRONMENT variable set to Development instead of Production. This often enables the Developer Exception Page.
# DANGEROUS: Environment variable set incorrectly on production serverexport ASPNETCORE_ENVIRONMENT=Development# or SET ASPNETCORE_ENVIRONMENT=Development (Windows)# or configured in launchSettings.json / web.config / IIS settings
ASP.NET Core: Ensure ASPNETCORE_ENVIRONMENT is set to Production on production servers. Use build configurations (Release) that disable debugging symbols and enable optimizations. Use app.UseExceptionHandler() instead of app.UseDeveloperExceptionPage() in production (Startup.cs).
ASP.NET Framework: Set <compilation debug="false"> in the production web.config. Use <customErrors mode="On" defaultRedirect="~/ErrorPages/GenericError.html">.
// Startup.cs - Configure() (ASP.NET Core - Secure)public void Configure(IApplicationBuilder app, IWebHostEnvironment env){ // SECURE: Only use developer page in Development environment. if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/Home/Error"); // Generic error handler app.UseHsts(); } // ... rest of configuration ...}// Ensure ASPNETCORE_ENVIRONMENT=Production is set via server env var,// web.config, Azure App Service settings, etc.
Check the production server’s environment variables (ASPNETCORE_ENVIRONMENT). Review the deployed web.config for <compilation debug="false"> and <customErrors mode="On">. Trigger an application error; verify that a generic error page is shown, not the detailed Developer Exception Page or Yellow Screen of Death (YSOD). Check response headers for any debug-related information.
Trigger errors (PHP syntax errors, framework exceptions). Verify generic error pages are shown, not Ignition/Whoops or raw PHP errors. Check environment variables (APP_DEBUG) and phpinfo() output (if accessible, which it shouldn’t be in production!) for display_errors. Check server logs for details.
Check the NODE_ENV environment variable on the production server. Trigger application errors. Verify that generic error messages are returned in the response body and no stack traces are included. Check server logs for detailed error information.
Trigger application errors. Verify that generic static error pages (e.g., public/500.html) or custom application error pages are shown, not the detailed Rails debug exception page. Check log/production.log for appropriate log levels and absence of excessive debug info.