55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
# Auth Threat Model (Bot Service)
|
|
|
|
Date: 2026-02-15
|
|
Scope: REST API (`/api/trade`, `/api/close`, `/api/chat`) + websocket auth path + Supabase token verification
|
|
|
|
## Security Objectives
|
|
|
|
- Only authenticated users can execute profile-bound trading actions.
|
|
- No cross-profile privilege escalation is allowed.
|
|
- Stolen/forged JWTs are rejected by issuer/audience policy when configured.
|
|
- Runtime controls produce auditable logs for rejected and accepted trade actions.
|
|
|
|
## Trust Boundaries
|
|
|
|
- Browser/dashboard client (untrusted input boundary).
|
|
- Bot service API/websocket layer (authz/authn enforcement boundary).
|
|
- Supabase auth/token service (identity trust boundary).
|
|
- Exchange connectors (execution boundary).
|
|
|
|
## Key Threats and Controls
|
|
|
|
1. Unauthenticated trade execution
|
|
Control: `requireAuth` middleware on sensitive REST routes and websocket auth middleware.
|
|
|
|
2. Token replay/forgery with mismatched issuer/audience
|
|
Control: `verifyAccessToken` validates via Supabase `auth.getUser(token)` and optional claim checks:
|
|
- `SUPABASE_JWT_ISSUER`
|
|
- `SUPABASE_JWT_AUDIENCE`
|
|
|
|
3. Cross-profile access (`profile_id` not owned by caller)
|
|
Control: profile ownership checks via Supabase before routing manual trade/close actions.
|
|
|
|
4. Privilege abuse and request flooding
|
|
Control: route-level rate limits + audit logging (`trade_request`, `close_request`, `chat_profile_control`).
|
|
|
|
5. Missing lifecycle accountability after execution
|
|
Control: deterministic `trade_id` flow, lifecycle reconciliation scripts, and websocket payload contract checks.
|
|
|
|
## Assumptions
|
|
|
|
- Supabase access-token signature validation remains source-of-truth via `auth.getUser`.
|
|
- Service role key stays server-side only.
|
|
- TLS is enforced at deployment ingress.
|
|
|
|
## Residual Risks
|
|
|
|
- If issuer/audience env vars are unset, claim restrictions are not enforced (intentional compatibility mode).
|
|
- Secret hygiene and repository history purge are operational tasks and remain outside runtime code controls.
|
|
|
|
## Operational Requirements
|
|
|
|
- Set `SUPABASE_JWT_ISSUER` and `SUPABASE_JWT_AUDIENCE` in production.
|
|
- Keep route audit logs retained and monitored.
|
|
- Run CI security checks and gitleaks on every main branch change.
|