Charon/docs/implementation/E2E_SECURITY_ENFORCEMENT_FAILURES_SPEC.md

E2E Security Enforcement Failures Remediation Plan (2 Remaining)

Context

• Branch: feature/beta-release
• Source: docs/reports/qa_report.md
• Failures: /api/v1/users setup socket hang up (Security Dashboard navigation), Emergency token baseline blocking (Test 1)

Phase 1 – Analyze (Root Cause Mapping)

Failure A: /api/v1/users setup socket hang up (Security Dashboard navigation)

Symptoms

• apiRequestContext.post socket hang up during test setup user creation in:
  • tests/security/security-dashboard.spec.ts (navigation suite)

Likely Backend Cause

• Test setup creates an admin user via POST /api/v1/users, which is routed through Cerberus middleware before auth.
• If ACL is enabled and the test runner IP is not in security.admin_whitelist, Cerberus will block all requests when no active ACLs exist.
• This block can present as a socket hang up when the proxy closes the connection before Playwright reads the response.

Backend Evidence

• Cerberus middleware executes on all /api/v1/* routes: backend/internal/api/routes/routes.go
  • api.Use(cerb.Middleware()) and protected.POST("/users", userHandler.CreateUser)
• ACL default-deny behavior and whitelist bypass: backend/internal/cerberus/cerberus.go
  • Cerberus.Middleware and isAdminWhitelisted
• User creation handler expects admin role after auth: backend/internal/api/handlers/user_handler.go
  • UserHandler.CreateUser

Fix Options (Backend)

1. Ensure ACL cannot block authenticated admin setup calls by moving Cerberus after auth for protected routes (so role can be evaluated).
2. Add an explicit Cerberus bypass for /api/v1/users setup in test/dev mode when the request has a valid admin session.
3. Require at least one allow/deny list entry before enabling ACL, and return a clear 4xx error instead of terminating the connection.

Failure B: Emergency token baseline not blocked (Test 1)

Symptoms

• Expected 403 from /api/v1/security/status, received 200 in:
  • tests/security-enforcement/emergency-token.spec.ts (Test 1)

Likely Backend Cause

• ACL is enabled via /api/v1/settings, but Cerberus treats the request IP as whitelisted (e.g., 127.0.0.1/32) and skips ACL enforcement.
• The whitelist is stored in SecurityConfig and can persist from prior tests, causing ACL bypass for authenticated requests even without the emergency token.

Backend Evidence

• Admin whitelist bypass check: backend/internal/cerberus/cerberus.go
  • isAdminWhitelisted
• Security config persistence: backend/internal/models/security_config.go
• ACL enablement via settings: backend/internal/api/handlers/settings_handler.go
  • SettingsHandler.UpdateSetting auto-enables feature.cerberus.enabled

Fix Options (Backend)

1. Make ACL bypass conditional on authenticated admin context by applying Cerberus after auth on protected routes.
2. Clear or override security.admin_whitelist when enabling ACL in test runs where the baseline must be blocked.
3. Add a dedicated ACL enforcement endpoint or status check that is not exempted by admin whitelist.

Phase 2 – Focused Remediation Plan (No Code Changes Yet)

Plan A: Diagnose /api/v1/users socket hang up

1. Confirm ACL and admin whitelist values immediately before test setup user creation.
2. Check server logs for Cerberus ACL blocks or upstream connection resets during POST /api/v1/users.
3. Validate that the request is authenticated and that Cerberus is not terminating the request before auth runs.

Acceptance Criteria

• POST /api/v1/users consistently returns a 2xx or a structured 4xx, not a socket hang up.

Plan B: Emergency token baseline enforcement

1. Verify security.admin_whitelist contents before Test 1; ensure the test IP is not whitelisted.
2. Confirm security.acl.enabled and feature.cerberus.enabled are both true after the setup PATCH.
3. Re-run the baseline /api/v1/security/status request and verify 403 before applying the emergency token.

Acceptance Criteria

• Baseline /api/v1/security/status returns 403 when ACL + Cerberus are enabled.
• Emergency token bypass returns 200 for the same endpoint.

Phase 3 – Validation Plan

1. Re-run Chromium E2E suite.
2. Verify the two failing tests pass.
3. Capture updated results and include status evidence in QA report.

Risks & Notes

• If security.admin_whitelist persists across suites, ACL baseline assertions will be bypassed.
• If Cerberus runs before auth, ACL cannot distinguish authenticated admin setup calls from unauthenticated setup calls.

Next Steps

• Execute the focused remediation steps above.
• Re-run E2E tests and update docs/reports/qa_report.md.

Status: SUSPENDED - Supersededby critical production bug (Settings Query ID Leakage) Archive Date: 2026-01-28