Nota.college← Back to home

Security

Last updated: May 20, 2026

This page describes the security measures actually implemented in Nota. It is written plainly and is intended to be accurate, not promotional. Anything not yet in place is listed under Known limitations.

1. Identity & authentication

  • Passwords are hashed with bcrypt (12 rounds); plaintext is never stored or logged.
  • Sessions use JWTs with a 7-day expiry. The signing secret must be at least 32 characters and is required in production. The token is an HttpOnly cookie, so page JavaScript cannot read it.
  • TOTP two-factor authentication is supported, with hashed single-use backup codes.
  • Forgot-password responses are identical for known and unknown emails (no account enumeration).
  • Password reset tokens are single-use, time-limited, and stored only as a hash.
  • SSO via Google OIDC today; SAML 2.0 / Shibboleth for institutions is on the roadmap.

2. Authorization

  • Workspace access is role-based (owner / editor / viewer), checked on the server before any mutation.
  • Account-type gates (undergrad / postgrad / professor) are server-enforced, not just hidden in the UI.
  • Public share links are read-only and tokenized.
  • The acting user is always taken from the verified JWT, never from the request body.

3. Data at rest

  • LMS tokens, Zotero API keys, and LTI private keys are encrypted with AES-256-GCM (versioned key envelope).
  • Uploads are stored under server-generated keys — the client filename never appears in the path.

4. Data in transit

  • HTTPS/TLS is enforced and HSTS is enabled.
  • Content-Security-Policy is set via Helmet, including frame-ancestors 'none' (clickjacking protection).
  • CORS uses a strict per-environment origin allowlist; localhost is rejected in production.

5. Input validation

  • Every request body is validated against a typed schema before reaching business logic.
  • File uploads are restricted to an explicit MIME-type allowlist.
  • The AI assistant has prompt-injection guardrails and answers only from provided context.
  • Redirect targets are sanitized to prevent open-redirect abuse.

6. Rate limiting

Per-scope throttling protects sensitive and high-traffic endpoints (tight limits on auth and AI).

7. Injection & mass-assignment

  • Prisma (parameterized queries) is used throughout; the few raw queries bind parameters, never concatenate.
  • Clients cannot set protected fields (e.g. admin status) by adding them to a request body.

8. Audit & observability

  • Resource mutations are recorded in an activity log.
  • Client-side errors are captured server-side with route and user-agent context.
  • A health endpoint is exposed for uptime monitoring.

9. LTI 1.3 (Blackboard / Moodle / Canvas)

  • Tool JWTs are RS256-signed with a rotating keypair; a public JWKS is served for platforms.
  • A one-time nonce store protects against launch replay.
  • Incoming platform JWTs are verified against the platform's remote JWKS.

10. Compliance posture

  • GDPR: account deletion cascades and removes user data; a retention window applies after a request.
  • FERPA-aligned: student data is isolated per workspace with no cross-workspace leakage.
  • SOC 2: not certified yet — on the roadmap.

11. Known limitations

  • Real-time collaboration is not enabled by default.
  • Exam-lock / proctoring is best-effort; browser-based locks can be circumvented.
  • SOC 2 certification is not yet in place.
  • Third-party penetration testing is planned, not yet completed.

12. Reporting a vulnerability

Please report security issues to security@nota.college. We follow responsible disclosure and ask for a reasonable embargo (up to 90 days) while a fix is prepared and deployed.