[Monitoring] Ingest hardening

[2witstudios]

Summary

Monitoring ingest currently persists raw query-string context and uses dual persistence paths for api_metrics, creating sensitive-data exposure risk and potentially inconsistent metrics records.

Evidence

• Request context extracts all query params:
  • /Users/jono/production/PageSpace/packages/lib/src/logging/logger-config.ts:58
• Middleware forwards query into ingest payload:
  • /Users/jono/production/PageSpace/apps/web/src/middleware/monitoring.ts:357
• Ingest route persists query inside system_logs.metadata:
  • /Users/jono/production/PageSpace/apps/web/src/app/api/internal/monitoring/ingest/route.ts:114
• Redaction list does not include common OAuth params like code/state:
  • /Users/jono/production/PageSpace/packages/lib/src/logging/logger.ts:133
• API metrics written through both buffered middleware flush and ingest path:
  • /Users/jono/production/PageSpace/apps/web/src/middleware/monitoring.ts:88
  • /Users/jono/production/PageSpace/apps/web/src/app/api/internal/monitoring/ingest/route.ts:74

Why This Matters

• OAuth and similar endpoints can leak sensitive query artifacts into persisted logs.
• Two write paths to api_metrics increase risk of inconsistent or duplicate records and complicate incident correlation.

Proposed Work

1. Implement query-param allowlist or sensitive-key denylist before persistence.
2. Redact sensitive query values (code, state, tokens, secrets, etc.) at ingest boundary.
3. Consolidate api_metrics to a single authoritative persistence path (or mark source + dedupe deterministically).
4. Align this with issue [Monitoring] Session ID preservation #538 so correlation fields remain complete.

Acceptance Criteria

• Sensitive query params are not persisted in raw form.
• api_metrics write path is single-source or explicitly deduplicated with source attribution.
• Tests cover redaction for OAuth callback-style query params and metric-path consistency.

[2witstudios]

Closing — deep code verification found this is a false positive.

Claims verified false:

• "Query params forwarded to ingest" — sanitizeIngestPayload() explicitly sets query: undefined before persistence
• "Query persisted in system_logs.metadata" — sanitizer strips it
• "OAuth params not redacted" — moot, query params never reach the logger

What actually happens: Query extraction occurs at logger-config.ts:58, but the ingest sanitizer (ingest-sanitizer.ts:85) strips query params before they reach any persistence layer. The dual write path for api_metrics is intentional design, not a bug.

No security gap exists here.