Description
Returning an exception's string representation or its args values directly in an HTTP response can expose implementation details, including file paths, SQL errors, internal hostnames and configuration values. An attacker may use that information to bypass input validation, refine an injection attempt or investigate the environment.
Potential impact
- Internal paths, database structure or service names may be disclosed.
- Attackers may find it easier to refine malicious input.
- Responses may reveal too much detail about authentication or authorization failures.
Remediation
- Record exception details in access-controlled server logs, excluding passwords, tokens and other secrets.
- Return a generic error message and an appropriate status code to clients.
- Use a shared exception-handling layer in Flask, FastAPI or Django to standardize error responses.
- Disable framework debug error pages in production.
Examples
Before
python
@app.route("/bad")
def server_bad():
try:
do_computation()
except Exception as e:
return str(e)
After
python
@app.route("/safe")
def server_safe():
try:
do_computation()
except Exception:
current_app.logger.exception("request failed")
return "Internal error", 500
Explanation:
- Before: Returns the detailed exception message in the response body.
- After: Keeps details in logs and returns a generic message to the user.