TRUST & SECURITY
Security at Reacta
This page is written for institutional IT and security reviewers. It describes how Reacta stores data, what we encrypt, how we authenticate users, and what institutional controls are available. We update it as our posture changes. Last updated October 2026.
Questions or a security report? security@reacta.io
AT A GLANCE
01. DATA
What we store and where
| Data category | Storage | Region | Encrypted at rest |
|---|---|---|---|
| User accounts, labs, inventory, reactions | Neon PostgreSQL | AWS US East 1 (N. Virginia) | AES-256-GCM (Neon default) |
| File attachments (SDS, references, lab notes) | Cloudflare R2 | Cloudflare auto-region | AES-256 (Cloudflare default) |
| Session tokens (JWTs) | Client cookie only | Not stored server-side | Signed with NEXTAUTH_SECRET |
| SSO client secrets | Neon PostgreSQL | AWS US East 1 (N. Virginia) | AES-256-GCM application-layer encryption (separate key from database) |
| Stripe payment data | Stripe | Stripe-managed | PCI DSS Level 1. Reacta never touches raw card data. |
Cloudflare R2 does not currently guarantee a specific geographic region for object placement. If EU data residency is a hard requirement, contact us. Regional configuration is on our roadmap.
02. ENCRYPTION
In transit and at rest
In transit
All traffic is served over HTTPS via Vercel's edge network, which enforces TLS 1.2 as the minimum version and supports TLS 1.3. HTTP requests are redirected to HTTPS automatically. Internal traffic between the Next.js runtime and Neon uses TLS enforced by Neon's connection pooler (PgBouncer).
At rest
Neon encrypts all data at rest using AES-256-GCM. Cloudflare R2 encrypts all objects at rest using AES-256. Passwords are stored as bcrypt hashes (cost factor 10) and can never be reversed or read.
03. AUTHENTICATION
How users sign in
Credential login
Email and password. Passwords are hashed with bcrypt before storage. Reacta cannot read or recover a user's password. Sessions are JWT tokens stored in an httpOnly, Secure, SameSite=Lax cookie; they are not stored in the database and cannot be revoked server-side before natural expiry.
OIDC Single Sign-On
Organisations can configure an OIDC identity provider (Okta, Microsoft Entra ID, Google Workspace, Keycloak, PingFederate, or any OIDC-compliant IdP). When configured, users with a matching email domain see a "Continue with SSO" button on the login page and are redirected to your IdP.
- PKCE flow. No client secret exposure in browser.
- Short-lived state and code verifier stored in httpOnly cookies (10-min TTL)
- New users provisioned automatically on first SSO login
- SAML support is on the roadmap
Rate limiting
Authentication endpoints are rate-limited to prevent brute-force attacks.
04. ACCESS CONTROL
Who can see what
Access is enforced server-side on every API route. A user can only read or write data that belongs to labs and organisations they are a member of.
- Lab owner (PI)Full read/write on their lab. Can invite and remove members.
- Lab memberRead/write on that lab's data. Cannot change lab settings or remove other members.
- Org admin (owner)Manages org settings, SSO config, catalogue and procurement mode. Cannot access individual lab data directly.
- Org memberInherits org settings. Access to labs is still governed by lab membership.
05. INSTITUTIONAL CONTROLS
Controls available to org admins
Minimal-data mode
When enabled, inventory, supplier, and billing features are turned off. Members can use reaction drawing, stoichiometry, and the NMR predictor without any chemical inventory data being stored. Enforced at the API layer, not just the UI. Useful while an institutional IT review is in progress, or for labs that only need analytical tools.
Full details: see the minimal-data mode documentation provided on request.
Procurement mode
Org admins can disable supplier price comparison entirely, or lock it to an institutional catalogue (no external supplier links shown to users).
SSO enforcement
When SSO is configured for an email domain, users with that domain see the SSO button on login. Standard credential login remains available as a fallback; forced-SSO (disabling password login) is on the roadmap.
06. SUB-PROCESSORS
Third-party services we use
| Provider | Purpose | Location |
|---|---|---|
| Vercel | Application hosting, CDN, edge network | Global (US-based entity) |
| Neon | PostgreSQL database | AWS US East 1 (N. Virginia) |
| Cloudflare R2 | File attachment storage | Cloudflare auto-region |
| Stripe | Payment processing and subscription billing | US (PCI DSS Level 1) |
| PubChem (NCBI / NIH) | Chemical data enrichment (GHS, SMILES, CAS; outbound API only, no user PII sent) | US government API |
07. COMPLIANCE
Current posture and roadmap
08. RESPONSIBLE DISCLOSURE
Reporting a vulnerability
If you discover a security vulnerability in Reacta, we ask that you report it to us privately before public disclosure, giving us reasonable time to investigate and remediate.
Please email security@reacta.io with a description of the issue, the steps to reproduce it, and the potential impact. We will acknowledge receipt within 2 business days.
We do not currently offer a bug bounty programme, but we do credit researchers in our release notes when they agree to disclosure.
CONTACT
Security issues: security@reacta.io
IT review / procurement questionnaires: contact form
Data Processing Agreements: available on request via our contact form