Security disclosure policy

1. Scope

In scope

The following surfaces are in scope for security reports:

• p31ca.org — static hub, all published HTML/JS pages and JSON contracts.
• bonding.p31ca.org — BONDING chemistry builder (client-side app + multiplayer KV backend).
• donate-api.phosphorus31.org — Stripe Checkout Worker (authentication, parameter validation, redirect logic).
• k4-personal, k4-cage, k4-hubs, k4-agent-hub Workers — authentication, authorization, session management, data isolation between users/vertices.
• github.com/p31labs — published packages and public repositories for issues such as supply-chain vulnerabilities, hardcoded secrets in committed code, or unsafe dependency resolution.

Out of scope

• Cloudflare platform-level infrastructure issues — report those to Cloudflare’s disclosure program.
• Stripe payment processing vulnerabilities — report those to Stripe’s security team.
• Theoretical or hypothetical vulnerabilities without a clear, demonstrated exploit path.
• Denial-of-service or load-testing attacks — do not test against production endpoints. Contact us first if you want to test resilience.
• Social engineering attacks targeting P31 Labs personnel.
• Physical access attacks.
• Reports generated by automated scanners without manual verification of exploitability.
• Third-party library CVEs that have no practical exploit path in our deployment.
• Missing security headers on static pages where there is no demonstrated attack scenario (we welcome these as low-priority suggestions, not vulnerabilities).

2. How to report

Send your report to:

We do not currently operate a formal bug bounty program and cannot promise financial rewards, but we do commit to acknowledging valid reports, coordinating on a fix timeline, and crediting researchers who want to be acknowledged (with their permission) in a public disclosure or changelog.

3. What to include in your report

A useful report includes:

• Affected surface: Full URL, Worker host name, or repository and file path.
• Type of vulnerability: For example, authentication bypass, data isolation failure, stored XSS, insecure direct object reference, exposed secret, SSRF, etc.
• Reproduction steps: Step-by-step instructions to reproduce the issue. Include HTTP requests, payloads, or screenshots where helpful.
• Impact assessment: What data or functionality is at risk? Could this affect other users? Is there potential for privilege escalation?
• Environment: Browser, OS, any tools used.
• Optional — suggested fix: If you have a patch or mitigation idea, we welcome it.
• Optional — your PGP key: If you want an encrypted reply, include a public key or key ID.

Please limit your testing to what is necessary to demonstrate the vulnerability. Do not access, modify, or exfiltrate data beyond what is needed to prove the issue.

4. Response timeline

• Acknowledgment: We will acknowledge your report within 5 business days of receipt.
• Triage: We will assess severity and scope and provide an initial triage response within 10 business days.
• Fix timeline: We will work with you to agree on a remediation timeline proportional to severity. Critical issues (active data exposure, authentication bypass) will be treated as the highest priority.
• Coordinated disclosure: We ask that you refrain from public disclosure until we have shipped a fix or until a mutually agreed disclosure date has passed, whichever comes first.

We are a small nonprofit team. We will be transparent with you about our capacity and timeline. If you do not receive an acknowledgment within 5 business days, please follow up.

5. Safe harbor

P31 Labs, Inc. extends the following good-faith safe harbor to security researchers who comply with this policy:

• We will not pursue civil or criminal action against you for security research conducted in accordance with this policy.
• We will not refer your report to law enforcement unless you engage in conduct that goes materially beyond what is necessary to demonstrate the vulnerability (for example, exfiltrating large amounts of production data, or accessing data belonging to third parties).
• We consider research conducted under this policy to be authorized access for purposes of the Computer Fraud and Abuse Act and analogous state computer crime laws, to the extent our authorization is legally meaningful.

This safe harbor does not extend to attacks on third-party infrastructure (Cloudflare, Stripe, Google) or to conduct that violates third-party terms of service. We cannot authorize access to systems we do not own or operate.

6. Coordinated disclosure

We follow a coordinated disclosure model. This means:

• We will keep you informed of our progress and share a draft of any public security advisory with you before publishing.
• We will credit you in any public advisory unless you request anonymity.
• If we are unable to ship a fix within a reasonable period and you wish to disclose, we will work with you to agree on a disclosure date and will attempt to publish a mitigation note simultaneously.
• We will not publish details of your report in a way that could harm you or your employer without your consent.

Our default target for coordinated disclosure is 90 days from acknowledgment, consistent with common industry practice. For critical issues affecting live user data, we will aim for a shorter timeline.

7. Additional out-of-scope guidance

The following will not be treated as valid security reports under this policy:

• Clickjacking on pages that have no sensitive actions or authenticated state.
• Self-XSS (where you can inject script only into your own browser).
• CSRF on logout or non-sensitive actions.
• Email header injection with no demonstrated exploit in our mail flow (we do not operate a mail server).
• Content injection on static pages with no authentication context.
• SSL/TLS configuration findings that are not practically exploitable against our users (Cloudflare manages our TLS termination).
• Lack of rate limiting on non-sensitive, unauthenticated endpoints where no personal data is at risk.

8. Contact