# 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`:

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:

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
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:

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:

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)

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.


See for yourself – run a scan on your code right now