Security

1. Exchange API Key Encryption

When you add an exchange API key to CWS Trading Platform, it is encrypted immediately before storage using AES-256-GCM — a symmetric authenticated encryption algorithm widely used for securing sensitive credentials at rest.

The encryption key is a 256-bit secret stored as an environment variable on our server — it is never written to the database, never committed to source control, and never transmitted outside our infrastructure. Without this key, the encrypted ciphertext stored in the database is unreadable.

The plaintext API key exists in server memory only for the fraction of a second required to encrypt it on the way in, or to decrypt and use it for a trade operation on the way out. It is never written to disk in plaintext.

2. How Keys Are Used

Your API keys are only decrypted in memory on the trading worker shard assigned to your account — the isolated process that actually places and manages your grid orders. The web application never holds decrypted keys; it only handles the encrypted form.

Decrypted keys are used exclusively to authenticate requests to your exchange (Coinbase or Alpaca). They are never logged, never stored in any intermediate cache or file, and never transmitted to any party other than your exchange.

We recommend configuring your exchange API keys with trade-only permissions and no withdrawal access. This limits the blast radius if credentials were ever compromised — the attacker could not move funds off your exchange, only view and trade.

3. Data Isolation via Row Level Security

Our database (Supabase / PostgreSQL) enforces Row Level Security (RLS) on all user-facing tables. Every query is automatically scoped to the authenticated user's own rows — a database-level guarantee that one user's data cannot be returned in another user's session, even if there is a bug in the application layer.

Administrative operations (shard routing, health monitoring, support) use a separate server-side service role that bypasses RLS only for the specific operations that require it. This role is never exposed to client-side code or user sessions.

4. Transport Security

All traffic between your browser and CWS Trading Platform is served over HTTPS through a Cloudflare tunnel, which terminates TLS at the edge and proxies to our backend over an encrypted internal connection. HTTP connections are automatically upgraded to HTTPS.

Internal communication between the web server and trading worker shards uses token-based authentication. Every worker request from the web server carries a shared secret token that the worker validates before executing any command. This prevents unauthorized direct access to the worker's admin interface.

5. Payment Security

We do not store credit card numbers or payment instrument details on our servers. All billing is handled by Stripe, a PCI DSS Level 1 certified payment processor. Our servers only store a Stripe customer ID and subscription ID — references into Stripe's systems, not the card data itself.

Subscription status is synchronized to our database via Stripe webhooks so we can gate features appropriately, but the source of truth for billing always lives in Stripe.

6. Authentication

Authentication is provided by Supabase Auth, which supports email/password login with bcrypt-hashed passwords and Google OAuth. Sessions are managed via secure, HttpOnly cookies that cannot be read by client-side JavaScript.

We do not have access to your password. If you use email/password login, your password is hashed with bcrypt before storage — we store only the hash and cannot recover the original value. If you use Google OAuth, your password lives entirely within Google's systems.

7. Infrastructure

The CWS Trading Platform runs on dedicated virtual private servers hosted at Hetzner Cloud (EU data center). Servers run Ubuntu 22.04 LTS with automatic security updates enabled. SSH access is restricted to key-based authentication — password authentication is disabled.

Worker processes are managed by PM2 and run under isolated OS processes. Each trading shard handles only the instances assigned to it; cross-shard access is not possible at the process level.

8. What We Do Not Do

• We do not store API keys in plaintext at any point in the pipeline.
• We do not log decrypted API keys in application logs.
• We do not share your API keys or account data with third parties.
• We do not use advertising trackers or sell your data.
• We do not initiate withdrawals — our exchange API usage is limited to reading account state and placing/canceling trade orders.

9. Responsible Disclosure

If you discover a security vulnerability in CWS Trading Platform, please report it responsibly. Do not publish or exploit the vulnerability — contact us first so we can investigate and patch it.

Send vulnerability reports to [email protected]. We will acknowledge your report within 48 hours and keep you updated on our response. We appreciate responsible disclosure and will credit researchers who help improve our security (with their permission).

10. Questions

For general security questions or concerns, contact us at [email protected] or [email protected].