Skip to content
PixelPrivate

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.