Newer
Older
cortex-hub / docs / reviews / feature_review_dependencies_identity.md

Code Review Report: Feature 19 โ€” Dependency Injection & Identity Propagation

This report performs a deep-dive audit of the Hub's dependency injection container and identity resolution logic in dependencies.py, focusing on Zero-Trust Security, Resource Management, and Service Lifecycle.


๐Ÿ—๏ธ 12-Factor App Compliance Audit

Factor Status Observation
IV. Backing Services โœ… Success Safe DB Contexts: The get_db dependency (Line 13) correctly implements the generator pattern with a finally: db.close() block. This prevents database connection exhaustion during high-concurrency API burstsโ€”a common failure mode in distributed AI Hubs.
VI. Processes ๐Ÿ”ด Major Risk Identity Header Spoofing: The system derives current user identity solely from the X-User-ID header (Line 23). If the Hub is deployed without a hardened reverse proxy that strips unauthenticated internal headers, any external attacker can achieve full administrative access by simply sending X-User-ID: admin in their HTTP requests.

๐Ÿ” File-by-File Diagnostic

1. app/api/dependencies.py

The wiring layer that provides services and identity to the Hub's REST endpoints.

[!CAUTION] Lack of Cryptographic Identity Verification Line 31: user = db.query(models.User).filter(models.User.id == x_user_id).first() The get_current_user dependency performs a direct database lookup based on a raw string ID from an HTTP header. There is no cryptographic signature (JWT/MAC) verification at the Hub level.

Recommendation: Transition from raw X-User-ID headers to signed JWTs or implement a shared secret "Inter-Service Token" if an upstream proxy is responsible for authentication. At minimum, the Hub should log a warning if settings.OIDC_ENABLED is true but no JWT signature is present.

Identified Problems:

  • Implicit Service Contract: The ServiceContainer (Line 59) uses setattr for dynamic service registration. While flexible, this obscures the application's service dependency graph from both developers and static analysis tools.
  • Hardcoded Anonymous Fallback: Currently, there is No "Anonymous" mode in the dependencies. All endpoints effectively require a user ID. If the system is intended to have a "Public RAG" mode, this dependency needs a permissive fallback path.

๐Ÿ› ๏ธ Summary Recommendations

  1. Harden Identity Resolution: Implement a trusted "Proxy Secret" or transition to JWT-based identity resolution to prevent header spoofing in environments without a secure perimeter.
  2. Explicit Service Attributes: Transition the ServiceContainer from dynamic setattr to explicit property-based registration to improve code discoverability and IDE support.
  3. Scoped Error Responses: Improve the "User not found" error (Line 34) to differentiate between an invalid user ID and a missing identity header for better frontend debugging.

This concludes Feature 19. I have persisted this report to /app/docs/reviews/feature_review_dependencies_identity.md. Should I investigate the networking configuration (Envoy or Nginx) to verify if existing perimeter guards mitigate the header spoofing risk?