Zero Trust & Security Hardening

While the Hoox dashboard features a highly secure, custom cookie-based authentication middleware, wrapping your dashboard and operator management APIs inside Cloudflare® Zero Trust (Access) provides an enterprise-grade security perimeter.

By placing your deployment behind Cloudflare® Access, you can enforce Multi-Factor Authentication (MFA), restrict access to specific GitHub/Google SSO identities, evaluate device posture, and drop malicious scanner payloads at the DNS level before they ever hit your workers.

CLI / TUI remote operators

hoox tui --remote is fail-closed: it requires HOOX_API_TOKEN / --token, or Cloudflare® Access service-token env vars:

# Server (Worker secret) — must match client token
wrangler secret put OPERATOR_API_KEY

# Client
export HOOX_API_TOKEN=…                    # Bearer → OPERATOR_API_KEY
export CF_ACCESS_CLIENT_ID=…               # optional Access service token
export CF_ACCESS_CLIENT_SECRET=…
export HOOX_TRANSPORT=access               # optional; auto when Access env set
hoox tui --remote --api-url https://mgmt.example.com

Management routes (all require Bearer):

GET /health stays public for liveness. Do not put operator Bearer on TradingView® /webhook.

Recommended layout:

1. Separate hostnames — gateway.example.com for TradingView® /webhook (IP allowlist + body apiKey); mgmt.example.com for /v1/* only.
2. Access application on mgmt.example.com (SSO for browsers; service token for CLI/TUI).
3. Application Bearer (HOOX_API_TOKEN ↔ OPERATOR_API_KEY) enforced by requireOperatorAuth.
4. Optional — Cloudflare® Tunnel so the origin is not on the public internet; Enterprise — API Shield mTLS client certificates for device-bound identity.

Do not put long-lived full-account CLOUDFLARE_API_TOKEN values into TUI debug logs or world-readable config files. Prefer scoped API tokens for deploy vs read-only monitor; ~/.hoox/config.json is written with mode 0600.

For tunnel vs Access decision tables, probe expectations, and hoox tunnel check, see Private ingress.

🏗️ The Zero Trust Protective Boundary

• Zero Public Exposure: The dashboard isolate does not evaluate public logins directly.
• MFA Gate: Users are intercepted by a secure Cloudflare® authentication card at the nearest edge PoP.
• Zero Cost: Cloudflare®'s Zero Trust free tier includes up to 50 users, which is more than enough for a personal algorithmic trading desk.

⚡ 1. Step-by-Step Dashboard Access Setup

Step 1: Enable Zero Trust on Your Account

1. Log in to the Cloudflare® Dashboard and click Zero Trust on the sidebar.
2. If this is your first time, follow the onboarding prompts to register a unique Team Name (e.g. alpha-trading.cloudflareaccess.com).

Step 2: Create a Self-Hosted Application

1. In the Zero Trust dashboard, navigate to Access > Applications and click Add an application.
2. Select Self-hosted.
3. Application Name: Hoox Dashboard Cockpit.
4. Session Duration: Select your preference (e.g. 24 Hours to prevent constant login prompts).
5. Application Domain: Enter the custom domain mapped to your dashboard worker (e.g., hoox.my-trading-empire.com).

Step 3: Configure Authorization Policies

1. Click Next to proceed to the Policies tab.
2. Policy Name: Allow Admin Only.
3. Action: Allow.
4. Configure Rules:
   • Include: Select Emails and enter your personal email address (enables Email OTP).
   • Include (SSO): Alternatively, select GitHub Org/Teams or Google Workspace to enable SSO integrations.
5. In the Require block, you can optionally require a valid security key (MFA) or device posture check (e.g. verifying that your laptop runs a specific OS version).

Step 4: Map Identity Providers & Save

1. In Settings > Authentication, link your desired login providers (Google Workspace, GitHub OAuth, or Email OTP).
2. Save the application.
3. Open your browser and navigate to your custom domain (https://hoox.my-trading-empire.com). You will be intercepted by your Cloudflare® Access card. Once authorized, you are passed cleanly to your Next.js dashboard.

🧱 2. Strict WAF Webhook IP Allow-listing

To ensure that only TradingView® official servers can fire signals to your /webhook entryway:

1. Under your Cloudflare® DNS zone dashboard, navigate to Security > WAF > Custom Rules.
2. Click Create Rule.
3. Rule Name: Restrict /webhook to TradingView® IPs.
4. Field: URI Path | Operator: equals | Value: /webhook.
5. And: IP Source Address | Operator: is not in | Value: paste TradingView® official IP ranges (keep the list current from TradingView® docs).
6. Action: Block (or Challenge).
7. Save. All unauthorized traffic hitting /webhook is dropped instantly at the DNS edge, preventing any V8 compute load.

# CLI helpers for the same zone
hoox waf status
hoox waf rules add ip-allowlist <TRADINGVIEW_CIDR>
hoox waf rules list

⚙️ 3. Optional: Bypassing Local Dashboard Auth

Once your custom domain is wrapped inside Cloudflare® Access, the dashboard's built-in login form (DASHBOARD_USER, DASHBOARD_PASS) becomes redundant.

To streamline access:

1. Edit the Next.js middleware.ts file inside workers/dashboard/src/.
2. Toggle the authentication checker to leverage Cloudflare®'s Access headers:
   typescript[ COPY ]

   // Next.js Edge Middleware
   export function middleware(request: Request) {
     // Verify the JWT payload injected in headers by Cloudflare® Access
     const cfAccessJwt = request.headers.get("Cf-Access-Jwt-Assertion");
     if (cfAccessJwt) {'{'}
       // Cloudflare® has already authenticated the session. Bypass local login.
       return NextResponse.next();
     {'}'}
     // Fallback to local cookie checks...
   {'}'}
   

🔗 Next Steps

• Next.js Dashboard worker Profile — Review OpenNext compilation and asset bindings.
• System Observability & Metrics — Setup time-series logging and Analytics Engine tables.