Security
How we protect your data, and how to report a vulnerability.
Reporting a vulnerability
If you believe you have found a security vulnerability in Helmdesk, email security@helmdesk.dev. Please include enough detail to reproduce the issue — affected URL or endpoint, steps, and any proof-of-concept.
We aim to acknowledge reports within 3 business days and to provide a remediation plan within 14 days of confirming an issue. We will credit reporters who ask to be credited once a fix has shipped.
Machine-readable contact details are published at /.well-known/security.txt.
Safe harbour
We will not pursue legal action against researchers who act in good faith and follow this policy. Good faith means:
- Test only against accounts and projects you own or have permission to test
- Do not access, modify, or exfiltrate another tenant's data — if you can demonstrate cross-tenant access, stop and report it
- Do not run denial-of-service, spam, or high-volume automated scanning
- Do not use social engineering or physical attacks against our staff or vendors
- Give us a reasonable opportunity to remediate before public disclosure
We do not currently run a paid bug bounty. Reports are handled by a human, not a triage vendor.
Tenant isolation
Helmdesk is multi-tenant. Every table carries PostgreSQL row-level security policies scoped to the owning account, so isolation is enforced by the database rather than only by application code.
Data is organised as account → project → records. Account members hold an owner, admin, or member role; members see only the projects they are explicitly assigned to.
Each project additionally has separate live and sandbox data planes. A sandbox API key cannot read or write live data, and sandbox activity never sends real email.
Encryption
- All traffic is served over HTTPS/TLS. HTTP is redirected.
- Data at rest is encrypted by our database and object storage providers.
- Email provider credentials you configure are encrypted with AES-256-GCM before storage, using a key held outside the database.
- API keys are stored as hashes. The full key is shown once at creation and cannot be retrieved afterwards.
- Passwords are hashed by Supabase Auth; we never see or store them.
Access control
- API keys carry granular scopes (for example
tickets:read,emails:send) so a key can be limited to exactly what an integration needs. - Keys support IP allowlists (IPv4, IPv6, and CIDR ranges) and expiry dates.
- Keys can be revoked immediately from the dashboard.
- Public API requests are rate limited per key.
- Account members can be disabled without deleting their history.
Audit logging
Meaningful changes — ticket assignment, replies, closures, member invitations and removals, article publication and deletion — are written to an append-only audit log recording the actor, the entity, and a timestamp. Account owners and admins can review their account's activity from the dashboard.
Support access to your data
Our staff do not browse customer data as a matter of course. A small number of administrators can temporarily view an account in order to resolve a support issue. Every such session is time-limited and recorded in that account's audit log, so you can see exactly when it happened and who performed it.
Infrastructure
- Application hosting: Vercel
- Database, authentication, and file storage: Supabase (managed PostgreSQL)
- Automated database backups are managed by our database provider
- Application errors are monitored via Sentry
- Dependencies are updated regularly; CI runs lint, type checks, and tests on every change
A current list of the third-party services that process data on our behalf is maintained in our Privacy Policy.
Certifications and attestations
We want to be straightforward here rather than imply more than we have. Helmdesk does not currently hold a SOC 2 or ISO 27001 attestation, and we have not yet commissioned an independent penetration test.
Our underlying infrastructure providers do maintain their own attestations, but that covers their platforms, not our application.
If your procurement process requires an attestation, a completed security questionnaire, or a data processing agreement, contact us at security@helmdesk.dev and we will tell you honestly where we stand and on what timeline.
Sensitive data
Helmdesk is not designed for regulated health, payment card, or government-classified data. Do not submit protected health information (PHI) or full payment card numbers through tickets, feedback, or logs. We do not offer a Business Associate Agreement.
Contact
Moloks Technologies
Ottawa, Ontario, Canada
Security: security@helmdesk.dev
General: support@helmdesk.dev