Security & Trust

What's actually true about how your data is handled — and what isn't built yet.

This page follows the same rule as everything else ORION discloses: a stated fact is checked against the running code, not aspirational. If something below isn't true yet, it says so, rather than staying silent about it.

Data access

Row-level security on every table

Subscriptions, usage, predictions, watchlists, portfolios, API keys, and audit logs all have database-level row security enabled. Browser sessions (anonymous or signed in) have no direct database access at all — every read and write goes through the backend, which is the only holder of the service-role credential.

Your session, verified every time

Authentication tokens are re-verified against Supabase on every request. Tier/plan is never trusted from anything the browser sends — it's re-derived server-side from the subscription record on every call that matters.

Payments never touch our servers

Live checkout is currently disabled pending merchant review and production validation. When activated, card data is handled by Toss Payments; ORION's backend is designed to receive a provider-issued billing reference rather than a card number. Code presence is not presented as completed operational validation.

Secrets stay server-side

API keys and service credentials are environment variables on the backend only — never shipped to the browser, never logged in plaintext, never returned in any API response.

Reliability

Payment events are replay-safe

Every recurring charge and Toss webhook is idempotency-keyed and signature-verified — a duplicate or retried delivery is a safe no-op, never a double charge or a double-applied state change.

Usage limits fail closed, not open

If the system that enforces a plan's usage cap is ever unreachable, capped requests are rejected rather than silently allowed through unlimited.

Structured, reviewable logs

Failures are logged in a consistent, searchable format with masked identifiers — not left as unlabeled text an operator would need to happen upon by accident.

A written incident runbook exists

Investigation steps for failed payments, missing access, and failed analyses are documented in an internal operations runbook, not improvised during an incident.

What's honestly not true yet