Helpdesk security
Helpdesk security checklist
Before you launch a helpdesk, check authz, pii, abuse, uploads and compliance. The rules below are the ones this category most often gets wrong; each one is concrete enough to test.
Last checked
Security: authz
- Requesters see only tickets of their own organisation; internal notes are filtered at the query layer for non-agents; asset and change data is limited to asset_manager and agent roles.
- API keys are hashed at rest, scoped to one organisation, revocable and rate limited.
Security: pii
- Ticket bodies and attachments can hold personal and secret data; redact on request, mask in logs, and encrypt attachment storage; credential-looking strings in tickets are flagged.
Security: abuse
- Inbound email is verified (SPF/DKIM results from the provider), reply tokens are unguessable, auto-replies and mail loops are detected, and spoofed senders cannot add themselves to other organisations' tickets.
Security: uploads
- Attachments are type- and size-limited, scanned, served with content-disposition attachment and signed URLs; inline HTML is sanitised before rendering.
Security: compliance
- Public replies and status changes are append-only events; edits and deletions are audited; change approval requires a different person than the requester.
Compliance notes
- Personal data in tickets (applies to EU or UK requesters): Tickets frequently include personal data; support data export, deletion and retention rules per organisation.
- ITSM good practice (applies to IT service desks): Change approval, incident timelines and asset records support audit frameworks (ISO 27001, SOC 2) but the app does not certify an organisation.
- Email sending rules: Outbound mail must meet anti-spam law and sender authentication requirements; automatic replies must be rate limited.
Limits that stop abuse and surprise bills
- email per org day: daily outbound email ceiling per organisation, fails closed.
- inbound emails per org day: daily inbound ticket-creating email ceiling, excess is dropped with a bounce notice.
- scanning per org day: daily attachment scan budget; excess stays quarantined.
- storage gb per org: per-tenant attachment storage quota.
Test it yourself before launch
Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.
This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.
- Sign in as two different users and try to open each other's records by changing the id in the address.
- Submit each form with an empty value, a very long value and a script tag, and check the result.
- Call each write endpoint without signing in and check that it refuses.
FAQ
- What is the biggest security risk in a helpdesk?
- Requesters see only tickets of their own organisation; internal notes are filtered at the query layer for non-agents; asset and change data is limited to asset_manager and agent roles.
- Does a helpdesk have compliance obligations?
- Personal data in tickets, if you have EU or UK requesters: Tickets frequently include personal data; support data export, deletion and retention rules per organisation. This is a starting point, not legal advice.
- Will Forge64 certify my app as secure?
- No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free