Security & Protection

01Password hashing and verification

Ticket passwords are never stored in plaintext. They are hashed using scrypt (N=16384, r=8, p=1) with a 16-byte cryptographically random salt and a 64-byte derived key. Verification is performed using timingSafeEqual to eliminate timing side-channel attacks.

Passwords gate content retrieval at the API layer: a password-protected ticket returns metadata only (title, item counts, expiration, and salt parameters), completely withholding payload items until the valid password is verified. Unlock attempts are limited to 8 attempts per 10 minutes per ticket.

02Bearer code entropy and enumeration protection

• Pickup codes are 6 characters generated from a 32-character unambiguous alphanumeric alphabet (approx. 30 bits of entropy), yielding over one billion distinct combinations.
• Code lookup endpoints are governed by sliding-window rate limits (40 requests per minute per IP) to prevent automated enumeration or brute-force code scans.
• The database maintains indexes strictly on valid, unexpired codes, preventing full-table scanning and ensuring fast query execution.

03Input validation and schema enforcement

• Every write is strictly validated via Zod schemas with type discrimination: links must be valid URLs, code snippets have length caps and language identifiers, and notes are bounded.
• Payload ceiling: A hard limit of 256 KB total size and 40 items per ticket protects database memory and prevents server exhaustion.
• All SQL queries are executed through parameterised Drizzle ORM statements, preventing SQL injection vulnerabilities.
• API responses strictly enforce Cache-Control: no-store and X-Content-Type-Options: nosniff headers.

04Administrative portal security

• Admin authentication uses separate scrypt password hashing verified against secure environment configuration.
• Admin sessions are managed via stateless, cryptographically signed HMAC-SHA256 tokens with a strict 7-day non-sliding expiry.
• Session cookies in production enforce __Host- prefixes, requiring HTTPS, HttpOnly, and SameSite=Lax flags.
• All state-changing administrative endpoints enforce CSRF Origin and Referer validation and sliding-window brute-force lockout (5 failed attempts per 15 minutes).

05Transport encryption and data lifecycle

All production traffic is served exclusively over HTTPS with HTTP Strict Transport Security (HSTS).

Data deletion is permanent: when a ticket expires or is burned early, the MySQL row is removed immediately. No soft-delete flags, archives, or retention queues remain.

06Responsible disclosure process

We value the contribution of independent security researchers who identify potential vulnerabilities in our implementation.

If you discover a security concern, please report it through our Contact page at /contact under the 'Security & Vulnerability Disclosure' category. Please include reproduction steps, environment details, and proof-of-concept payloads. We request that researchers refrain from probing other users' tickets, degrading platform availability, or executing destructive actions against production infrastructure.