Security

This page summarises what NovuHub does to protect a workspace and what the operator is responsible for. Report vulnerabilities to the address in /.well-known/security.txt.

Accounts and sessions

• Passwords are hashed with Werkzeug's default (scrypt); minimum 12 characters, common-password block list, and no password containing the person's name or email.
• Optional TOTP two-factor authentication with backup codes.
• Email verification before first sign-in; sign-in throttling shared across workers (database-backed, no Redis needed).
• Sessions expire after 14 days, Remember me after 30; cookies are Secure, HttpOnly and SameSite=Lax.
• OpenID Connect with PKCE for SSO; SCIM provisioning behind a bearer token compared in constant time. Deactivated accounts cannot sign in.

Authorisation

• Every request is scoped to the caller's workspace; a cross-workspace isolation test runs in CI.
• Section access is enforced server-side (NOVUHUB_ENFORCE_DATA_ACCESS=1): the API returns only the collections a person may see.
• The Decision Intelligence (Analysis) section is available only to the founding workspace owner and is never rendered for other members.
• API tokens are workspace-scoped, hashed at rest, and rate-limited.

Web application protections

• CSRF: origin/referer check on every state-changing request plus a token on auth forms.
• Content Security Policy without unsafe-eval, plus X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and HSTS.
• All user-supplied text is escaped when rendered; a stored-XSS probe over 20 fields × 29 views runs in the assessment suite.
• Request bodies are capped (JSON 413 on overflow); uploads are size-limited and served with safe content types.
• Outbound requests (webhooks, IdP discovery, mail providers) go through an SSRF guard that refuses private, loopback and link-local destinations.

Data

• Attachments live on your own storage (local disk or your bucket); nothing is sent to third parties except the providers you configure (email, AI, billing).
• Per-record sharding and optimistic concurrency (version check on every save) prevent lost updates between simultaneous editors.
• GDPR tooling: export, erasure, PII-access log, consent versions, retention.
• Backups: ops/backup.sh with offsite push and a tested-restore script.

Supply chain and process

• Dependencies are pinned in requirements.txt and checked with pip-audit; bandit is at zero medium/high findings and ruff enforces lint rules including the security (S) set (ruff.toml). The CI workflow runs the backend and front-end suites and proves the production bundle builds; the snippet in DEPLOY-phase1-hardening.md adds the audit/lint steps.
• 113 backend and 17 front-end tests run on every push, including SSO/SCIM, hardening, rate-limit and XSS-guard suites.
• Every release is recorded in the changelog with its security-relevant switches.

Operator checklist

1. Set a unique SECRET_KEY and keep it stable.
2. Terminate TLS at nginx; keep COOKIE_SECURE=1.
3. Configure NOVUHUB_SECURITY_CONTACT and a monitored support mailbox.
4. Turn on offsite backups and the weekly restore test.
5. Prefer SSO + SCIM for companies with an identity provider.
6. Keep the server updated (git pull + the upgrade steps) and watch the changelog for new switches.