Skip to content
CerebroChain

Security

Security posture, in plain language.

The controls that protect your data — authentication, TLS, tenant isolation, the audit log, rate limiting and a web application firewall — each documented on this page. If you find something we missed, the vulnerability disclosure path is at the bottom of this page.

Data handling

  • Encryption in transit. TLS 1.2+ on every public surface, single certificate covering cerebrochain.com, www.cerebrochain.com, and app.cerebrochain.com, renewed via Let's Encrypt every 60 days.
  • Backups. The production database (MongoDB 8) is backed up every night at 03:00 UTC; each backup is kept for 14 days on the server and 30 days in an off-site copy.
  • Tenant isolation. Every database write carries a tenantId; every query filter requires it. The middleware that loads req.tenant rejects any request whose subscription is suspended, expired, or read-only.
  • US hosting. The production server and database run in the United States.

Authentication and access control

  • Password hashing. bcrypt on every account, with strength rules enforced server-side (uppercase, lowercase, digit, special, 8-char minimum).
  • JWT sessions. Short-lived access tokens; refresh tokens rotated per session. Tokens are signed with a secret rotated 2026-04-26 and stored only server-side.
  • Google OAuth. Production-wired since 2026-04-26 as an alternative sign-in path. Consent is scoped to email + profile only.
  • RBAC. Role + permission checks on every mutation. Cerebrix-mediated mutations require explicit operator approval before they fire.
  • Plan gate. Workspace features need an active plan or trial, checked on the server for every workspace request — a lapsed workspace gets a 402, whatever the UI shows. No feature is held back by plan tier: every plan runs the same software.

Application hardening

  • Security headers. Helmet on the API, and a Content-Security-Policy that loads scripts only from our own origin (plus Plausible on the marketing site) and limits connections to our origins, Stripe, Google Fonts and Plausible; images may load from any HTTPS source. The console sends frame-ancestors 'none' and X-Frame-Options: SAMEORIGIN, so other sites can't frame it.
  • Rate limiting. Per-route limiters on auth, password-reset, and the public Stripe checkout endpoint.
  • CSRF. The console and the API authenticate with a bearer header, never a cookie, so a request from another site can't act for a signed-in user.
  • Input validation. Sign-up, sign-in and profile changes validate their input before their handlers run.
  • Stripe webhook integrity. Every incoming webhook is verified against the Stripe signing secret before any tenant state is touched.
  • WAF + DDoS. Cloudflare in proxy mode in front of the apex and app domains. Bot-management rules + automatic challenge on traffic anomalies.

Observability and audit

  • Audit log. Inventory, order, label, sign-in and API key changes land in your audit trail with the person who made them, where they came from (console, connector or system) and when — with before and after values for stock and order status. Owners and admins export any date range to CSV in one click, up to 500 events at a time.
  • Application logs. Structured JSON via Winston, retained on the production VPS with rotation. Sensitive fields (tokens, passwords, full webhook payloads) are redacted at the logger boundary.
  • Health endpoints. /api/health reports liveness only, and /api/health/ready whether the database and cache are reachable — neither reports a version or environment. We don't expose internal stack traces in error responses.

Dependency hygiene

  • Dependency audit on every CI run. The pipeline fails on high or critical advisories; the few with no fix published yet are allowlisted by ID.
  • Pinned versions. Production deps install from the committed lockfiles (npm ci for the server, pnpm install --frozen-lockfile for the web apps) — no surprise transitive updates between deploys.
  • Secret scanning. A pre-commit secret scan guards the repo — it runs on staged files, and CI re-runs it against the diff. .env files are git-ignored.

Privacy and compliance

  • GDPR / CCPA. Access, export and deletion requests go through the contact form and are completed within 30 days (see the Privacy Policy). A data processing agreement is available on request.
  • Subprocessors. Hostinger (server, database, backups), Cloudflare (DNS, CDN, WAF), Stripe (payments), Resend (transactional email), Google (optional sign-in; Workspace email), Anthropic and Groq (Cerebrix answers), Shippo (shipping labels), Plausible (cookie-free site analytics). What each one receives is on the Privacy Policy.

Vulnerability disclosure

Found something? We want to hear about it before anyone else does.

  • Email [email protected] with reproduction steps. Encrypted attachments welcome.
  • We respond by email.
  • Good-faith research that doesn't degrade service for other tenants is welcome — we won't pursue legal action.
  • We credit reporters in release notes when they want it.