How to report an issue

Please send security reports to [email protected].

A useful report should include a clear description of the issue, affected endpoints or components, reproduction steps, proof of concept where applicable, and an explanation of practical impact. Reports that are generic, theoretical, or not reproducible may not be reviewed.

What a strong report looks like

High-quality reports are clear, reproducible, and focused on real-world impact. A good submission typically includes:

• Summary: One or two sentences describing the issue and affected area
• Steps to reproduce: Exact steps, including URLs, requests, or actions
• Proof of concept: Screenshots, request/response samples, or minimal code
• Impact: What an attacker could realistically do
• Scope: Which users, roles, or systems are affected

Summary:
User can access another user's vault metadata via direct object reference

Steps:
1. Login as user A
2. Navigate to /api/vault?id=1234
3. Modify id to another user's vault
4. Observe metadata returned

Impact:
Unauthorized access to vault structure and metadata

Notes:
Requires valid session but no additional privileges
                

Session management note

PhotonFile intentionally separates password changes from global session revocation. Users can explicitly revoke active sessions across devices using the dedicated session control in account settings.

Behavior where active sessions persist after a password change, unless the user separately chooses to revoke them, is not considered a security vulnerability by itself.

Username and public identity model

PhotonFile usernames are private login aliases. They are not public account identities, public trust signals, or durable ownership handles. PhotonFile uses account identity and email address for account recovery, team permissions, ownership, and audit/activity attribution. Public Vault Share pages and Secure Inbox pages do not use the account username as the recipient-facing owner identity.

PhotonFile intentionally supports Unicode usernames. A username that is visually similar to another username, or a previously used username becoming available after a username change, is not considered a security vulnerability by itself unless the report demonstrates unauthorized access, permission bypass, account takeover, data exposure, or a PhotonFile workflow that exposes the username as a trust signal contrary to this policy.

We do not currently plan to make usernames public. If PhotonFile introduces a public account identity feature in the future, outside of existing email-based account identity and intentionally user-controlled Vault branding, we will treat that as a security-sensitive design change and apply appropriate anti-impersonation controls before launch.

Reward policy

While PhotonFile does not run a formal bounty program, we do reward meaningful, well-documented security findings that materially impact user safety or platform integrity.

However, we do recognize and reward high-quality, impactful security findings at our discretion. Reports that demonstrate clear, reproducible issues with meaningful impact to user security are much more likely to be considered.

Safe harbor

We will not pursue legal action against researchers who act in good faith and stay within the bounds of responsible testing.

• Do not access, alter, or retain other users' data
• Do not intentionally degrade, disrupt, or overload service availability
• Do not attempt social engineering, phishing, or physical attacks
• Do not publicly disclose the issue before we have had reasonable time to review and address it

Responsible disclosure expectations

We ask researchers to minimize impact during testing, avoid data exfiltration beyond what is strictly necessary to demonstrate an issue, and give us a reasonable opportunity to investigate and resolve reported vulnerabilities before any public disclosure.

How PhotonFile approaches security