# Sensitive Data Leaks
Disclosing system information helps an adversary learn about your web application and form a plan of attack. You should try to reveal as little about your technology stack and architecture as possible, beyond what is essential for your users to know. Revealing system information makes life easier for an attacker, and gives them a playbook of vulnerabilities they can probe for.
Here are some common ways websites leak sensitive data:
* Error conditions that display stack traces or database error messages to the user.
* Open directory listings that allow exploration of the server’s file system.
* Unsanitized comments in HTML and template files the reveal system details.
## How to Prevent Data Leaks in Python
### Keep Error Reporting on the Server
Disable client-side error reporting in your production environment. Observe how the Flask framework uses different error pages in development and production modes, distinguished by whether the environment variable `FLASK_ENV` is set to `development`:
| “`python @property def debug(self) -> bool: “””Whether debug mode is enabled. When using “flask run“ to start the development server, an interactive debugger will be shown for unhandled exceptions, and the server will be reloaded when code changes. This maps to the :data:`DEBUG` config key. This is enabled when :attr:`env` is “’development’“ and is overridden by the “FLASK_DEBUG“ environment variable. It may not behave as expected if set in code.**Do not enable debug mode when deploying in production.**””” return self.config[“DEBUG”] “` |
The default error page only contain a generic error message (e.g. “An error occurred”), whereas the development-mode error page will log full stack traces, and even allow interactive execution of Python code.
### Sanitize Error Messages
Make sure error messages returned from the database or containing system information are logged, but not shown to the user. When running in non-development mode the Flask web-server will show a generic error message to the user, while the detailed error is written to the logs for investigation:
| “`python def log_exception(self, exc_info) -> None: “””Logs an exception. This is called by :meth:`handle_exception` if debugging is disabled and right before the handler is called. The default implementation logs the exception as error on the :attr:`logger`. “”” self.logger.error( f”Exception on {request.path} [{request.method}]”, exc_info=exc_info ) “` |
### Separate Dynamic and Static Resources
Ensure static resources and dynamic content are stored in separate directories, so a malicious user cannot snoop through your code and configuration files. Here’s how to specify the directory containing static files (like JavaScript code and images) in the Flask web-server:
| “`python from flask import Flaskapp = Flask(__name__, static_folder=’static’) “` |
### Disable the “Server” Header
Consider disabling the `Server` header and the (non-standard but common) `X-Powered-By` header, and making the session cookie name generic. This will give your keep an attacker guessing about what your technology stack is, which makes attacking it harder. In the Gunicorn WSGI container, you can configure this header in your `gunicorn.conf.py` config file:
| “`python import gunicorn# Make the server name completely generic. gunicorn.SERVER_SOFTWARE = ‘Server’ “` |
### Further Considerations
* Ensure any comments in template files don’t contain sensitive data! It’s easy to leave in notes about server names and addresses that will get passed to the client-side. Attackers know this, and will scan comments in HTML for IP addresses and URLs.
* Ensure server-side log messages do not contain sensitive information like passwords or credit card numbers – this should mitigate the harm an attacker can do if they manage to steal your server’s log files.
## CWEs
* [CWE-200](https://cwe.mitre.org/data/definitions/200.html)
