Error Handling & Information Disclosure Prevention

description: Error handling and information disclosure prevention (safe failures, error messages, stack traces) languages:

• c
• go
• java
• javascript
• kotlin
• php
• python
• ruby
• swift
• typescript alwaysApply: false

rule_id: codeguard-0-error-handling

Error Handling & Information Disclosure Prevention

Implement secure error handling that prevents information leakage while maintaining system integrity and enabling effective debugging.

Core Principles

Fail Secure

• When errors occur, default to the most secure state (deny access, close connection).
• Never assume "success" when an operation fails; treat unknown states as failures.
• Ensure partial failures don't leave the system in an insecure intermediate state.

Defense in Depth

• Multiple layers of error handling: application, framework, infrastructure.
• Errors at one layer should not bypass security controls at other layers.
• Log errors at the appropriate layer for debugging without duplication.

Error Message Design

User-Facing Messages

• Return generic, non-technical messages to users (e.g., "An error occurred. Please try again.").
• Never expose internal details: database names, table structures, file paths, stack traces, SQL queries.
• Use consistent error message format across the application.
• Provide actionable guidance without revealing system internals.

Good Examples:

"Invalid username or password."
"Unable to process your request. Please try again later."
"Access denied."

Bad Examples:

"SQLException: Table 'users' not found in database 'prod_db'"
"NullPointerException at UserService.java:142"
"Error: /var/www/app/config/database.yml not readable"

Internal/Developer Messages

• Log detailed error information for debugging (stack traces, context, variables).
• Include correlation IDs to link user-facing errors to detailed logs.
• Store logs securely with access controls; never expose via API or UI.

Stack Trace Protection

Production Environment

• Disable stack trace display in production; enable only in development.
• Configure web frameworks to use custom error pages.
• Remove debug endpoints and verbose error modes before deployment.

Framework Configuration Examples

Python/Flask:

app.config['DEBUG'] = False
app.config['PROPAGATE_EXCEPTIONS'] = False

@app.errorhandler(Exception)
def handle_exception(e):
    app.logger.error(f"Error: {e}", exc_info=True)
    return {"error": "An unexpected error occurred"}, 500

Node.js/Express:

app.use((err, req, res, next) => {
    console.error(err.stack);
    res.status(500).json({ error: 'An unexpected error occurred' });
});

Java/Spring:

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleException(Exception e) {
        log.error("Error occurred", e);
        return ResponseEntity.status(500)
            .body(new ErrorResponse("An unexpected error occurred"));
    }
}

Error Categories and Handling

Authentication Errors

• Use identical messages for invalid username vs. invalid password.
• Maintain consistent response times to prevent timing attacks.
• Log failed attempts with enough context for threat detection.

Authorization Errors

• Return 403 Forbidden without revealing why access was denied.
• Don't disclose whether a resource exists when access is denied.
• Log authorization failures with user context.

Validation Errors

• Provide specific field-level feedback without exposing validation logic.
• Sanitize error messages to prevent injection via error content.
• Rate-limit validation attempts to prevent enumeration.

System Errors

• Catch and handle all exceptions at application boundaries.
• Use circuit breakers for downstream service failures.
• Implement graceful degradation when dependencies fail.

Information Disclosure Prevention

Sensitive Data in Errors

• Never include passwords, tokens, API keys, or secrets in error messages or logs.
• Mask or redact PII in logs (credit cards, SSNs, email addresses).
• Sanitize user input before including in error messages.

System Information

• Remove server version headers (Server, X-Powered-By, X-AspNet-Version).
• Disable directory listing and default error pages.
• Use generic 404 pages that don't reveal application structure.

Error Response Headers

# Remove revealing headers
X-Powered-By: (remove)
Server: (remove or set to generic value)

# Add security headers
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

Logging and Monitoring

What to Log

• Error timestamp, type, and severity level.
• Correlation ID linking to user request.
• User identifier (non-PII) if authenticated.
• Affected resource or operation.
• Stack trace (to secure logs only).

What NOT to Log

• Passwords, tokens, session IDs (full).
• Credit card numbers, SSNs, PII.
• Detailed query parameters containing sensitive data.
• Encryption keys or secrets.

Log Format

{
    "timestamp": "2025-01-01T12:00:00Z",
    "level": "ERROR",
    "correlation_id": "abc-123-xyz",
    "user_id_hash": "sha256:...",
    "error_type": "DatabaseConnectionError",
    "message": "Failed to connect to primary database",
    "action": "failover_initiated"
}

Recovery and Resilience

Transaction Rollback

• Ensure database transactions are rolled back on error.
• Release locks and resources on failure.
• Return system to consistent state.

Retry Logic

• Implement exponential backoff for transient errors.
• Set maximum retry limits to prevent infinite loops.
• Log retry attempts for monitoring.

Circuit Breaker Pattern

• Open circuit after threshold of failures.
• Allow periodic probes to detect recovery.
• Fail fast when circuit is open.

Implementation Checklist

Error Messages

• Generic user-facing error messages (no technical details).
• Detailed logging for developers (secure storage).
• Correlation IDs linking user errors to logs.
• Consistent error format across application.

Stack Traces

• Disabled in production environment.
• Custom error pages configured.
• Debug modes disabled before deployment.

Information Disclosure

• Sensitive data excluded from errors and logs.
• Server version headers removed.
• Directory listing disabled.
• 404 pages don't reveal structure.

Security Headers

• X-Content-Type-Options: nosniff
• X-Frame-Options configured.
• Revealing headers removed.

Resilience

• Transactions rolled back on error.
• Resources released on failure.
• Circuit breakers for external services.
• Retry logic with backoff.

Test Plan

Unit Tests

• Verify generic error messages for each error type.
• Confirm sensitive data not in error responses.
• Test correlation ID generation and propagation.

Integration Tests

• Verify custom error pages in production mode.
• Test error handling at API boundaries.
• Confirm transaction rollback on failure.

Security Tests

• Attempt to trigger verbose error messages.
• Check for information disclosure in 404/500 pages.
• Verify stack traces not exposed.
• Test error-based enumeration resistance.

OWASP References

• Error_Handling_Cheat_Sheet.md
• Logging_Cheat_Sheet.md
• XS_Leaks_Cheat_Sheet.md