1. How we protect Statsy
- Encryption. TLS everywhere, HSTS on our domains, backups encrypted before upload, and integration secrets encrypted at rest with AES-256-GCM.
- Accounts. Hashed passwords, email verification, rate-limited sign-in and reset, and every session revoked when a password is reset.
- Isolation. Every API request is checked against the workspace and role it acts for. API tokens are stored only as hashes and can be limited to one site.
- Infrastructure. Databases run on private networks with no public ports, and internal job endpoints are blocked at the edge. Client addresses are only trusted from verified proxy ranges, so rate limits cannot be dodged by forging headers.
- Minimal data. Visitor IP addresses are never stored, replays mask form inputs, and raw events expire after 90 days.
- Web protections. Strict security headers, no third-party scripts in the dashboard, and output escaping in emails and reports.
2. Reporting a vulnerability
If you find a security issue, email [email protected] with the steps to reproduce it. We will acknowledge within 3 business days, keep you updated, and credit you if you wish once it is fixed.
We will not take legal action against research that follows these rules:
- Only test against accounts you own or have permission to use, and stop as soon as you reach someone else’s data.
- Do not run denial-of-service, spam, social engineering or physical attacks, and do not degrade the service for others.
- Give us reasonable time to fix the issue before telling anyone else.
Out of scope: missing best-practice headers without a working exploit, self-XSS, rate limits on non-sensitive endpoints, and reports from automated scanners with no demonstrated impact.