Security
Security and responsible disclosure
PixelPrivate is a security product, so we hold ourselves to a high standard. If you find a problem, please tell us.
Report a vulnerability
Email [contact address not yet configured — set SECURITY_CONTACT_EMAIL] with a description, steps to reproduce and the potential impact. Our machine-readable contact is at /.well-known/security.txt.
What to expect
- Acknowledgement of your report as soon as practicable.
- Triage and an assessment of severity.
- Updates on remediation, and credit if you want it once fixed.
These are targets, not contractual commitments; no bounty program exists at this time.
Rules of engagement
- Test only against your own accounts and data.
- No denial of service, social engineering, or physical attacks.
- Do not access or modify other users’ data; stop and report if you encounter it.
- Give us reasonable time to fix before public disclosure.
In scope
pixelprivate.com and its API. Of particular interest: SSRF or filter bypasses in the scanner, tenant-isolation failures, authentication and session flaws, and injection.
Security practices
- Strict transport security, CSP, secure and HttpOnly cookies, SameSite.
- Server-side authorization for every tenant operation, plus database row-level security.
- SSRF-hardened scanner: public hosts only, pinned DNS, redirect re-validation, size and time limits.
- Rate limiting, bot protection, audit logs, dependency and secret scanning in CI.
Supported versions
Only the current production deployment is supported.
Known limitations
The Content-Security-Policy currently permits inline scripts for framework compatibility; hash-based hardening is on the roadmap. See the methodology for scanner limitations.