Security and vulnerability disclosure

Reporting a vulnerability

Email abuse@playbix.store with "SECURITY" in the subject. Please include what you found, how to reproduce it, and what an attacker could do with it.

We commit to:

• acknowledging your report within 3 business days;
• telling you our assessment and intended fix within 10 business days;
• keeping you updated until it is resolved;
• not pursuing legal action against you for good-faith research that follows the rules below.

Rules for good-faith research

• Use only your own accounts and your own test apps. Do not access, modify or exfiltrate another user's or developer's data — including any identity document.
• Do not run denial-of-service tests, spam our systems, or use automated scanners that degrade the service for others.
• Do not use social engineering against our staff, developers or users.
• Give us a reasonable chance to fix the issue before disclosing it publicly. We will not ask you to stay quiet indefinitely.
• Stop as soon as you have demonstrated the issue, and tell us.

We do not currently run a paid bug bounty. We will credit you publicly if you want that, and we will say so plainly rather than implying a reward that does not exist.

In scope

• playbix.store and its API
• The Playbix Android client
• Anything that lets one account read or change another's data, escalate to admin, or publish without review
• Anything that would let an app be installed without passing signature checks

Out of scope

• Vulnerabilities in third-party apps published on the store. Report those through the abuse form instead — we will contact the developer.
• Reports from automated scanners with no demonstrated impact.
• Missing hardening headers with no exploitable consequence.
• Android warning about installing from unknown sources. That is the operating system working correctly, and our installation guide explains it.
• Issues in Supabase, Cloudflare or Vercel themselves — report those to them.

What we do to protect users

Signature pinning

We record the signing certificate of an app's first approved release and permanently require it thereafter. This is enforced by a database constraint, not by application code, so no bug in our own upload path can bypass it. If a developer's account is compromised, the attacker still cannot ship a tampered update to people who already trust that app.

Malware scanning

Every uploaded file is checked against multiple antivirus engines before it can be reviewed. A file several engines call malicious is blocked automatically. A single detection does not block publication, because false positives on Android packages are genuinely common and auto-blocking on one hit would train reviewers to ignore the signal.

Private storage and signed downloads

App files are stored privately with no public URL. Downloads are served through short-lived signed links issued only after we have confirmed the version is approved. There is no way to obtain a build that was rejected.

Data isolation

Access is enforced row by row in the database rather than only in application code, so one account cannot read another's data even if a page or API route has a bug. Developers cannot approve their own apps, mark their own identity as verified, alter malware scan results, or change install counts — those are blocked at the database level.

Identity documents

Developer ID documents are stored under a separate private prefix, are never reachable through the public media route, are never sent to any third-party scanning service, and every view by a reviewer is written to an audit log. They are deleted once an application is decided. See the Privacy Policy.

Audit trail

Approvals, rejections, takedowns, identity verifications and document views are recorded in an append-only log that accepts no client writes. "Who approved this, and when?" always has an answer.

What we do not promise

We will not tell you the store is safe. Antivirus engines detect known threats, not novel ones. Human reviewers miss things. A developer can behave well for a year and then ship something harmful. Installing software from outside Google Play means extending trust to us and to the developer, and anyone who claims to have eliminated that risk is overselling.

What we do promise is that the checks described above are real, that they are enforced where they cannot quietly be skipped, and that we will act quickly when something gets through.

If you think an app on Playbix is malicious

Use the report form and pick "Malware". Those reports go to the top of the queue, and our policy is to remove first and investigate second. If users are at active risk, email abuse@playbix.store with URGENT in the subject as well.