Review Production Exposure of Environment and JSON Endpoints

[georgidhristov]

Description

DebugProbe currently keeps /debug/environment and /debug/json/{id} mapped in Production by default.

Tests confirm this behavior is intentional, but it should be reviewed from a security and product standpoint.

Current Behavior

When DebugProbe UI endpoints are disabled in Production, these endpoints may still remain available:

/debug/environment
/debug/json/{id}

This can expose debug-related metadata or trace details even when the main UI is not available.

Expected Behavior

Production endpoint exposure should be explicit and easy to understand.

If UI access is disabled in Production, related debug data endpoints should either also be disabled or clearly documented as intentionally available.

Suggested Fix

Review whether these endpoints should be controlled by the same Production UI protection rules.

Recommended options:

• Disable /debug/environment and /debug/json/{id} in Production unless AllowUiInProduction = true.
• Or keep them available, but document clearly why they are safe and intended.
• Add or update tests to lock the final decision.

Result

After this review:

• Production behavior becomes clearer.
• Security expectations are easier to understand.
• DebugProbe avoids accidentally exposing sensitive debug data.
• Tests and documentation match the intended product behavior.

[DevSars24]

Hi @georgidhristov! I'd love to work on this issue.
My approach:
Looking at DebugProbeExtensions.cs, the /debug/environment and /debug/json/{id} endpoints are currently registered outside the ShouldMapUiEndpoints() check, which means they remain accessible in Production even when the main UI is disabled.
My fix will be straightforward:

Move both endpoints inside the existing if (ShouldMapUiEndpoints(...)) block so they follow the same production rules as the UI
Update the existing test Production_keeps_machine_readable_debug_endpoints_available_by_default to reflect the new behavior
Add a test to verify both endpoints return 404 in Production when AllowUiInProduction is not set

No new options or configuration needed — the existing AllowUiInProduction flag will control everything consistently.
Could you please assign this issue to me? Happy to get started right away!

[georgidhristov]

Thanks for the detailed analysis. Sounds good to me—I've assigned the issue to you.