VELOX / Docs · Security ← Back to site Launch Terminal →

Security

How Velox handles keys, auth, deployments, and exposure surfaces. This is the current state — rough edges are honestly flagged.

Where your API keys live

Model API keys (CLAUDE_API_KEY, GEMINI_API_KEY, GROK_API_KEY) can live in two places depending on how you're running Velox:

EnvironmentKey storageExposure
Browser-only localStorage in your browser Present in JavaScript execution context. Not sent to any Velox server. Model calls originate from your device directly to Anthropic/Google/xAI.
Server cron mode Vercel env vars (encrypted at rest) Only read inside cron functions. Never returned in any API response.

Browser-mode caveat: keys stored in localStorage are readable by any script running on the same origin. Velox pages do not load third-party scripts except Google Fonts (CSS-only, no JS). You should:

  1. Never paste model keys on a machine you don't trust
  2. Clear localStorage when done on a shared machine
  3. Use separate, rotatable keys (e.g. Anthropic Console → create project-specific keys)

The anthropic-dangerous-direct-browser-access header

To call the Anthropic API from a browser, Velox sets anthropic-dangerous-direct-browser-access: true. This header tells Anthropic's API to allow a browser origin. It does not bypass any rate-limits or access controls — it only bypasses Anthropic's default same-origin enforcement.

Be aware that this means your Claude key is in-flight between your browser and Anthropic servers. Normal TLS applies.

Redis security

Velox uses Upstash Redis. Credentials:

  • KV_REST_API_URL — per-database URL; knowing this is insufficient
  • KV_REST_API_TOKEN — bearer token; knowing this grants full DB access

These are stored as Vercel env vars and are only accessed from server-side cron functions. They are never exposed to the browser. If a key leaks, rotate immediately in the Upstash dashboard.

API endpoint exposure

Known gap As of v0, /api/* endpoints are open to the public internet. Anyone who knows your deployment URL can hit /api/scan, /api/optimize?run=1, etc. and trigger real AI calls + Redis writes.

Mitigations in the current design:

  1. Cron gating — scheduled runs are gated by CRONS_ENABLED. While that flag is off, cron-triggered invocations no-op; only manual HTTP calls execute.
  2. Redis-only writes — endpoints can modify Redis state, but cannot move real money (there is no exchange integration yet).
  3. Rate-limiting from providers — Anthropic, Google, xAI all rate-limit. A malicious caller can't cause infinite AI spend in practice; they can cause some spend.

Planned (see roadmap): Bearer-token auth via CRON_SECRET env var, enforced on all /api/* endpoints. Vercel's cron scheduler will include the secret automatically; manual callers will need to pass Authorization: Bearer <secret>.

Until that ships, self-hosted deployments should put their Vercel domain behind a reverse-proxy ACL, or use Vercel's Protected Deployments feature.

Dependency supply chain

Velox's runtime dependencies are intentionally minimal:

@upstash/redis       # server-side Redis client
svelte               # frontend framework
vite                 # dev server / bundler
lightweight-charts   # chart component (no network access)

These are the only packages loaded on pages that handle user keys. Docs-only pages additionally load Google Fonts — CSS-only, no JS.

Reporting security issues

Please do not file security-sensitive issues on GitHub. Email security@velox.trade (or DM the maintainer on Discord). We aim to acknowledge within 24h.

If a discovered vulnerability is materially exploitable, we will:

  1. Confirm the issue and triage severity
  2. Ship a patch to main within 7 days for high-severity issues
  3. Credit the reporter in the release notes (unless anonymity is requested)

Changelog of security-relevant changes

See the changelog — security-affecting items are prefixed [security].