Security Statement

Draft — Effective date: [NOT YET PUBLISHED] · Version 0.1

This page describes NEXORA’s actual security practices as built today — not a certification, and not a claim of any particular compliance framework. Where a practice isn’t in place yet, we say so directly rather than imply otherwise.

Identity and access

Authentication is delegated to Clerk rather than built by us — we do not implement our own password storage or session handling. Machine access (the API) uses per-organisation API keys: only a one-way hash of each key is stored, the plaintext is shown exactly once at creation, and keys can be revoked instantly from the Console. Every request — human or machine — is scoped to a single organisation; no session or key from one organisation can read or act on another’s data.

Tenant isolation

Every database query that reads or writes organisation-scoped data is filtered by organisation at the query itself, not filtered afterward in application code. This is verified with an automated cross-organisation isolation check: two organisations’ usage events, API keys and subscription data are confirmed never to leak into each other’s queries.

Payments

Card numbers and other payment details never reach our servers — checkout happens on Stripe’s own hosted page, and we receive only a subscription status and Stripe’s own reference identifiers back. Incoming billing events are authenticated by verifying Stripe’s webhook signature before anything is processed; unsigned or incorrectly signed requests are rejected outright.

Audit logging

Actions your organisation takes — API key creation and revocation, product usage, subscription changes — are recorded with an actor, an organisation, a timestamp and an outcome, visible to your organisation in Console’s Usage and Analytics views.

Transport and infrastructure

All traffic to the Service is intended to be served over HTTPS/TLS. [TODO(launch): edge/TLS termination is not provisioned yet — this platform has not been deployed to production infrastructure. This statement should be reviewed and confirmed once it has been.] Database encryption at rest depends on the Postgres hosting provider selected; [TODO(launch): name the provider and confirm its at-rest encryption once selected].

What we have not done yet

In the interest of not overstating our posture: NEXORA has not undergone an independent third-party security audit or penetration test, and does not hold any formal security certification (e.g. SOC 2, ISO 27001) at this time. Our approach to date has been to verify specific mechanisms — tenant isolation, key hashing, webhook signature verification — with targeted, repeatable checks against real infrastructure during development, which is a different and lesser thing than an independent audit.

Reporting a vulnerability

If you believe you’ve found a security vulnerability in NEXORA, please report it to security@onenexora.com rather than disclosing it publicly. We ask that you give us a reasonable opportunity to investigate and address a report before any public disclosure, and that you do not access or modify data that isn’t your own while investigating. [TODO(launch): formalise a disclosure/bounty policy and response-time commitment once real infrastructure exists to triage against.]