Stack Traces Production

title: "Stack Traces in Production — Security Considerations for Error Details" description: "Stack traces in production API responses expose internal implementation details that aid attackers. Always log internally but return safe, generic messages to clients." date: 2026-06-28 lastmod: 2026-06-28 weight: 26 tags: [apis, error-handling] }

Stack traces reveal internal implementation details including file paths, library versions, and code structure. They must never be exposed in production API responses.

What You'll Learn

• Why stack traces are security risks
• Safe error logging practices
• Environment-aware error detail levels

Why It Matters

A stack trace in a production response gives attackers a map of your internal architecture, making targeted attacks easier.

Code Examples

# Environment-aware error detail
import os

def format_error(error, trace_id, request):
    is_debug = os.getenv("ENVIRONMENT") == "development"

    response = {
        "error": "INTERNAL_ERROR",
        "message": "An unexpected error occurred",
        "trace_id": trace_id
    }

    if is_debug:
        response["debug"] = {
            "exception": type(error).__name__,
            "message": str(error),
            "stack_trace": traceback.format_exc(),
            "file": os.path.relpath(
                getattr(error, "__traceback__", None)
            ) if hasattr(error, "__traceback__") else None
        }

    return response

// Safe error handling middleware
function errorHandler(err, req, res, next) {
  const traceId = uuidv4();
  console.error(`[${traceId}]`, err.stack);

  const response = {
    error: 'INTERNAL_ERROR',
    message: 'An unexpected error occurred',
    trace_id: traceId
  };

  // Only include debug info in development
  if (process.env.NODE_ENV === 'development') {
    response.debug = {
      name: err.name,
      message: err.message,
      stack: err.stack
    };
  }

  res.status(500).json(response);
}

Common Mistakes

1. Stack Traces in Production

The most common and dangerous mistake. Never expose stack traces.

2. Internal URLs in Error Messages

Don't include internal API URLs, server names, or IP addresses.

3. Database Error Propagation

PostgreSQL or MySQL error messages often reveal schema details.

4. Library Version Exposure

Error messages shouldn't reveal library versions or patch levels.

5. Inconsistent Debug Mode

Don't conditionally show stack traces based on user role or API key.

Practice Questions

1. Why are stack traces a security risk?
2. When can you show detailed error information?
3. What should you do with the original error?
4. What internal information should error messages avoid?
5. How do you handle database errors safely?

Answers:

1. They reveal file structure, library versions, and implementation patterns.
2. Only in development or staging environments, never in production.
3. Log it internally with full detail, and return a safe message.
4. File paths, server names, IP addresses, database table names, library versions.
5. Catch the database error, log it internally, return a generic server error.

Challenge: Audit a production API for stack trace exposure. Check all error handlers to ensure no internal details leak in responses.

FAQ