Skip to content

Security overview

A factual summary of the platform's security posture, written for institutional reviewers and security teams.

Transport and application

  • HTTPS everywhere, plain HTTP redirects to HTTPS, and responses carry HTTP Strict Transport Security (one year).
  • Session and CSRF cookies are Secure and the session cookie is HttpOnly, sessions are server-side with a bounded lifetime.
  • Cross-site request forgery protection on every state-changing request, clickjacking protection via frame denial, nosniff content-type handling, and a same-origin referrer policy.
  • Database access goes through the framework's ORM with parameterized queries throughout, no string-built SQL. Output encoding via template auto-escaping.
  • All third-party browser assets (UI frameworks and editors served from a CDN) are version-pinned with subresource-integrity hashes, a tampered file is refused by the browser.

Authentication and authorization

  • Researcher passwords are stored hashed and salted (Django's PBKDF2), with length, common-password, similarity, and numeric-only validators enforced.
  • Google sign-in is available, accounts using it inherit the user's Google MFA enforcement. Native TOTP MFA is on the roadmap.
  • Authorization is object-level ownership. A survey project is readable and editable only by its owner and explicitly invited, invitation-accepted collaborators, every researcher-facing endpoint checks this server-side. Participants can only submit responses.
  • Optional invisible bot protection (Google reCAPTCHA v3) on response collection, on by default for new surveys.

File handling

  • Uploads are validated against allowlisted types and size limits per surface.
  • Participant-submitted files and private library files are stored outside the web-served directory tree, they have no URL, the storage layer refuses to produce one, and the only read path is a permission-checked download stream available to the project's owner and collaborators. On-disk permissions deny world access and are applied by the storage layer at write time.
  • Public web-served media is delivered with nosniff and a restrictive Content-Security-Policy and is never executed server-side.

Deletion guarantees

Deleting a response, an asset (past its recycle bin), or an account erases the underlying file bytes from storage, removal is not a soft flag. Account deletion is self-service and covers all owned data, see Data handling.

Reporting a vulnerability

Reports are welcome at the security contact published on this site. Please include reproduction steps, we confirm receipt and keep reporters informed through to the fix.