Skip to main content

Security

Authoritative reference: security/trust-center (customer-facing).

Threat model (developer view)​

Noxys is itself a security tool. The threat model includes:

  1. Hostile users on customer endpoints — the extension must not be bypassable from a content script or compromised page.
  2. Hostile customers — the multi-tenant backend must enforce strict tenant isolation; no cross-tenant data leakage even with a compromised tenant.
  3. Hostile sub-processors — minimum-trust posture on every external dependency.
  4. Insider threat — Noxys staff must not be able to read raw prompts (default) without explicit tenant opt-in + KMS key release.

Secret management​

  • Local dev: .env.local files, gitignored. Templates checked in as .env.example.
  • Production: secrets in 1Password Vault → Vault Operator → Kubernetes secrets / Doppler.
  • CI: secrets via GitHub Actions encrypted secrets (project secrets only — no org-wide secrets except read-only deploy keys).
  • Rotation: at least quarterly for long-lived secrets; on demand for compromised secrets.

Hard rule: if a secret is committed to git for any reason, treat it as compromised, rotate immediately, document the incident.

Code-level security checklist​

Before any commit:

  • No hardcoded secrets (API keys, passwords, tokens, SSH keys, certs)
  • All user inputs validated with Zod (or equivalent in non-TS repos)
  • All DB queries are parameterized — no string concatenation
  • No unsanitised raw HTML insertion (use DOMPurify or text-only APIs)
  • CSRF protection on every state-changing endpoint
  • Authentication + authorization checked on every endpoint, not just the gateway
  • Rate limiting on every public endpoint
  • Errors do not leak stack traces, internal IDs, or PII to the client

Dependency security​

  • Audit: pnpm audit runs on every CI build; high-severity vulns fail the build.
  • Renovate: automated PRs for dependency updates (CI must pass before merge).
  • Lockfiles: committed and verified (pnpm install --frozen-lockfile in CI).
  • Pre-merge review: dependencies with new sub-dependencies require a manual scan before merge.

Authentication & authorization​

  • Customer authentication: OIDC via Microsoft Entra ID, Google Workspace, or Okta. No password authentication.
  • Internal authentication: GitHub OIDC + 1Password TOTP for production access.
  • Authorization: role-based (Admin / Viewer) — see console.
  • API tokens: scoped per-tenant, short-lived, revocable from the console.

Data protection​

  • Encryption at rest: AES-256-GCM via cloud provider KMS (AWS KMS in Frankfurt; OVH-managed keys in Gravelines).
  • Encryption in transit: TLS 1.3 only; HTTP Strict Transport Security (HSTS) enforced.
  • Per-tenant KMS keys for tenants on the raw-prompt-storage opt-in tier.
  • Data residency: EU only — no replication outside eu-central-1 / Gravelines.

Compliance​

Vulnerability disclosure​

Internal incident response​

When a security incident is detected:

  1. Stop — page the on-call (rotation in 1Password "On-Call" vault).
  2. Triage — Severity assigned within 1h: SEV-1 (data leak / auth bypass), SEV-2 (privilege escalation), SEV-3 (info disclosure), SEV-4 (low-impact).
  3. Contain — isolate affected systems; rotate compromised credentials; revoke active sessions.
  4. Communicate — SEV-1/SEV-2 trigger 72h customer notification; all severities logged in the incident tracking system.
  5. Postmortem — within 5 business days; published internally; remediations tracked as issues.

No-blame culture. Postmortems focus on system gaps, never on individual mistakes. The goal is to make the system catch the next occurrence automatically.

Hardening checklists​

  • VPS: Ansible playbook in noxys-infra/playbooks/harden-vps.yml.
  • K8s: PodSecurity admission restricted profile.
  • HTTP headers: CSP / HSTS / X-Frame-Options / X-Content-Type-Options on every public response.
  • Cookies: Secure, HttpOnly, SameSite=Lax (or Strict where applicable).
  • CORS: explicit origin allowlist per tenant; no wildcards.