Security practices

This page is an honest snapshot of how Traqly is built and operated today. It is not a marketing claim. Items marked planned are on the roadmap but not yet shipped.

Application security

• HTTPS everywhere · HSTS · TLS 1.2+
• JWT auth · short-lived sessions · per-request membership recheck (planned)
• bcrypt cost-12 password hashing
• API keys (trq_live_*) stored as bcrypt hashes
• Rate-limit on auth + track endpoints (express-rate-limit)
• Body-size limits on every endpoint (1 MB default, lower on pixel-bound routes)
• Strict input validation via Zod schemas on all /api/* POST routes

Data protection

• Pixel defaults to denied consent — no marketing identifiers leave the browser without explicit opt-in
• Email and phone hashed (SHA-256) in-browser before transmission
• IPs truncated to /24 for fingerprinting · full IP only for ≤ 7 days fraud window
• Workspace data isolated per-tenant at the database row level
• Daily off-site backups · 30-day rolling retention · annual restore drill

Infrastructure

• Hosted in EU (Germany) · no third-country data transfer for raw events
• Backend on private loopback · only HTTPS frontend exposed
• Compressed responses (gzip) on every route
• Health-probed reverse-proxy with circuit breaker per upstream vendor (planned)

Process

• Centralized audit log of administrative actions (planned)
• Sentry + structured logs for production observability (planned)
• Coordinated vulnerability disclosure: [email protected]
• SOC 2 Type II (planned, target 2027)

Reporting an issue

If you believe you have found a security issue, please email [email protected] with proof-of-concept details. We will acknowledge within 48 hours and credit you in the changelog if a fix ships.