ByteHeavy
ByteHeavy
ByteHeavy
Security & trust
Most agencies say 'bank-level security' and leave it at that. We'd rather show you the specifics — including the parts that are still in progress — because a vague promise is worth less than a checkable one.
Our ticket system runs on PostgreSQL with Row-Level Security enabled and forced, connected through a dedicated application role that is deliberately not a superuser. That means access-control rules live inside the database itself, not just in application code. We tested this directly: a session scoped to one client's email genuinely cannot read another client's tickets, even on the exact same database connection and role. If a future bug in our application code tried to query the wrong data, the database refuses before the query ever runs — the isolation doesn't depend on us remembering to write the right WHERE clause every time.
Every response carries a Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, and a restrictive Permissions-Policy — the standard defenses against clickjacking, MIME-sniffing attacks, and a chunk of XSS. Production builds ship without source maps, so the exact structure of our source code isn't handed to anyone who opens dev tools.
Every ticket and contact form endpoint is rate-limited per IP, and includes a honeypot field invisible to real users but often filled in automatically by bots — submissions that trip it get a fake success response instead of a rejection, so scripted abuse doesn't even learn it was blocked. All form input is validated server-side with a strict schema before it ever touches the database, regardless of what the frontend allows through.
We're not going to claim a feature exists before it does. Two-factor authentication (TOTP with a QR code) and a dedicated Rust-based auth/session service are designed and planned, but not yet running in production — right now, ticket lookup is by email match, which is a convenience mechanism, not a password-grade login. File attachments on tickets are intentionally not supported yet, specifically because we haven't built the malware-scanning layer we'd want in front of them. We'd rather ship a feature late than ship it insecure.
If you can't verify a security claim, it's marketing. We'd rather you could.