⚙️ Implementation: How should the DevActivityController be secured in productio...

Date: 2026-03-17
Time: 17:17:46 UTC
Session: gspace1-229.8
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the DevActivityController be secured in production?

Task: Not specified

🎯 Decision Made

Chosen:

Two layers: (1) DevActivityGuard checks NODE_ENV and ENABLE_DEV_ACTIVITY env var — throws NotFoundException (404) in production unless explicitly enabled, hiding the endpoint's existence entirely. (2) @Roles('developer', 'admin', 'system') decorator enforces role-based access via the global RolesGuard from AuthCoreModule.forRoot(). This means even in dev, only authenticated users with developer+ roles can query activity.

Options Considered:

1. No guard, rely on roles only (endpoint visible in prod)
2. IP whitelist (brittle, hard to maintain)
3. API key auth (adds key management complexity)
4. Guard + Roles double layer (chosen — secure, zero-config)

💭 Reasoning

Security-in-depth: the guard prevents accidental exposure in production (attackers can't even discover the endpoint exists — they get 404, not 403). The @Roles decorator provides authorization for development environments where the endpoint IS active. The RolesGuard is registered globally via APP_GUARD in AuthCoreModule.forRoot(), so it applies to all routes including those in imported modules like RequestActivityModule. No need to import AuthCoreModule in the activity module — the global guard handles it.

📁 Files Involved

• libs/libs-api/backend-core/src/lib/dev-activity/dev-activity.guard.ts
• libs/libs-api/backend-core/src/lib/dev-activity/dev-activity.controller.ts

🔗 Related

• Decision ID: dev_1773767866673_ocxwf5m
• Session: 229
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation