Security & Identity

Security Overview

Wallet Encryption

When you save a wallet with your Binance API key and secret, the credentials are encryptedbefore being written to the database. The encrypted ciphertext is stored inapi_key_enc and api_secret_enc columns. The plaintext values are never stored in the database.

Encryption uses AES-256-GCM with a server-side encryption key stored as an environment variable, separate from the database. This means:

• A database dump alone is not sufficient to recover API keys — the encryption key is required.
• The encryption key and database credentials are stored separately and have independent access controls.
• Ciphertext is authenticated (GCM) — tampered ciphertext will fail decryption and log a security warning rather than silently producing garbage output.

Credential Lifecycle

The full lifecycle of a credential from save to use:

1. Save: User enters API key + secret in the wallet form. The browser sends them over HTTPS. The server encrypts them immediately and stores only the ciphertext.
2. At rest: api_key_enc and api_secret_enc columns hold AES-256-GCM ciphertext. No plaintext exists in the database.
3. Fetch: When a live-mode project is due, the runner queries the wallet row by ID, verifying it is owned by the project's owner.
4. Decrypt: The runner calls decryptString() on each column. If decryption fails, the error is logged and the tick falls back to paper mode.
5. Use: The plaintext API key and secret are passed directly to the Binance SDK for a single connectivity check and/or MARKET order.
6. Zero: Immediately after use, the plaintext strings are overwritten with empty strings in memory. They are never logged, serialized, or transmitted beyond the Binance API call.

User Identity Model

User identity in Norena is represented by a UUID — the Supabase Auth user ID. This ID is the primary foreign key linking every piece of user data:

Row-level security policies in the database enforce this ownership model at the query layer — not just at the application layer. Even if a bug in application code attempted to read another user's data, the database would return empty results.

The user ID is a UUID generated by Supabase Auth on account creation. It is stable for the lifetime of the account. All strategies, runs, trades, and wallets are permanently associated with this ID.

Sandbox Isolation

Strategy code submitted by users is compiled and executed in a restricted Node.jsvm sandbox. The sandbox provides these guarantees:

• No filesystem access — fs, path, and all Node built-in modules are unavailable.
• No network access — fetch, http, https, net, and dns are unavailable. Strategy code cannot make outbound requests.
• No process access — process, require, import, and all module system functions are unavailable.
• No prototype pollution — Array, Object, Math, JSON, and Date are frozen. Strategy code cannot mutate these globals.
• Null-prototype global — the sandbox global has no prototype chain, preventing access to any inherited globals not explicitly whitelisted.
• Dual timeout — a synchronous timeout (via vm.Script) and an async deadline (via Promise.race) both enforce a 5-second hard limit per tick.

Per-user strategy isolation is enforced by the database ownership model, not the sandbox. Each project runs with the owner's user ID embedded in the broker context, ensuring that positions, logs, and trades are always written to the correct user's records.

Data Isolation

All user data is isolated at the database level using Supabase Row Level Security (RLS) policies. These policies mean that:

• API calls from the frontend are scoped to the authenticated user's session — no user can read or write another user's data.
• The backend runner uses a service role key but always scopes queries by owner_id = project.owner_id, enforcing the same isolation explicitly in application code.
• Wallet decryption explicitly verifies owner_id = p.owner_id before returning credentials — a wallet cannot be used by a project it does not belong to.

User Recommendations

These are steps you should take on your end to maximize security: