Skip to content

Redact HTTP error stack traces by default #2026

Closed

Description

@HocVoNgThai

Default configuration proposal

Change the default of http.error.excludeStackTraces to true so HTTP error responses use the existing redaction marker unless diagnostic stack traces are explicitly enabled.

The option already exists through #536 and PR #1461. This proposal changes its default, rather than adding another hiding mechanism. On main 0c481c0, the fallback in GlobalErrorWebExceptionHandler is false.

Expected behavior

  • Omitted property: use the existing REDACTED FOR SECURITY REASONS marker.
  • Explicit true: continue redacting.
  • Explicit false: continue returning diagnostic stack traces.

Keep status codes, messages, request IDs, and the response schema unchanged. This proposal only concerns the stackTrace field; it does not introduce a general error-message redaction policy.

Compatibility and validation

This is a behavior change for deployments that omit the option. Document the migration path: set http.error.excludeStackTraces: false to retain the previous diagnostic response behavior.

Tests with the real WebFlux error handler confirm the current default and exercise omitted, explicit-true, and explicit-false configurations. No additional vulnerability or CVE claim is made.

Activity

  1. kapybro commented on Oct 7, 2026

    @kapybro

    AI Summary

    This issue proposes changing the default value of http.error.excludeStackTraces to true so that HTTP error responses automatically redact stack traces with a security marker unless diagnostics are explicitly enabled. This improves default security without altering status codes, messages, or other response schemas. Deployments relying on previous diagnostic behavior must explicitly set the option to false.

  2. changed the title [-]BE: Redact HTTP error stack traces by default[/-] [+]Redact HTTP error stack traces by default[/+] on Oct 7, 2026
  3. added
    scope/backendRelated to backend changes
    type/enhancementEn enhancement/improvement to an already existing feature
    on Oct 7, 2026
  4. Haarolean commented on Oct 7, 2026

    @Haarolean
    Member

    why?

  5. kapybro commented on Oct 14, 2026

    @kapybro

    Further user feedback is requested. Please reply within 7 days or we might close the issue.

  6. kapybro commented on Oct 21, 2026

    @kapybro

    No feedback received within 7 days. Auto closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

scope/backendRelated to backend changestype/enhancementEn enhancement/improvement to an already existing feature

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions