Security
How we protect researcher and participant data — and how to reach us if you find a problem.
Reporting a vulnerability
Email security@myresearchlab.app. We aim to acknowledge within a few business days and coordinate disclosure — please give us a reasonable window (target: 90 days) to remediate before any public write-up. Machine-readable contact lives at /.well-known/security.txt.
Encryption
All traffic is served over HTTPS. The database (Neon Postgres) is encrypted at rest. Third-party credentials you connect (OSF, Prolific, AI provider keys) are encrypted application-side before storage and never returned to the browser.
Authentication
Sign-in is handled by Clerk (magic-link + OAuth). We don't store passwords. Sessions are scoped and expire; revoking a session takes effect immediately.
Workspace isolation
Every study, response, and asset belongs to a workspace, and every data read is filtered by your workspace membership — one workspace can never see another's data. Participant responses are identified only by an opaque token, not personal identity.
Participant-data boundary
Participant-facing pages run free of product analytics and error-tracking context. Diagnostics never carry participant answers or raw personal identifiers — only coarse, non-identifying technical context needed to fix bugs.
Rate limiting & abuse
Participant entry and answer submission are rate-limited to protect against abuse and accidental floods, without blocking legitimate respondents.
Sub-processors
We rely on a small set of vendors to run the service (hosting, database, authentication, email, AI providers you opt into). The current list and our privacy practices are documented in our privacy policy.
Dependencies & monitoring
Dependencies are updated on a weekly automated cadence, and runtime errors are aggregated and alerted so we can respond quickly. We do not currently hold a formal certification (e.g. SOC 2) — appropriate for our stage; we'll revisit as we grow.