Vulnerability Disclosure Policy

We value the security community. This policy outlines how to report vulnerabilities responsibly.

Effective Date: January 1, 2025 | Last Updated: {{LAST_UPDATED}}

1. Introduction

At ZPHC, security is a top priority. We are committed to protecting our users, systems, and data. We recognize that security researchers play a vital role in identifying vulnerabilities and helping us improve our security posture.

This Vulnerability Disclosure Policy (VDP) provides guidelines for security researchers to report potential vulnerabilities in our systems. We encourage responsible disclosure and are committed to working with the security community in a transparent and collaborative manner.

By participating in our vulnerability disclosure program, you agree to comply with this policy. We ask that you act in good faith and follow the guidelines outlined below.

2. Scope

2.1 In-Scope Assets

The following assets are within the scope of this policy:

  • zphc.cm — Primary website
  • *.zphc.cm — All subdomains
  • app.zphc.cm — Web application
  • api.zphc.cm — Public API endpoints
  • ZPHC mobile applications (iOS and Android)

2.2 In-Scope Vulnerability Types

We are interested in receiving reports about the following types of vulnerabilities:

  • Remote Code Execution (RCE)
  • SQL Injection (SQLi)
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Server-Side Request Forgery (SSRF)
  • Authentication and Authorization flaws
  • Insecure Direct Object References (IDOR)
  • Sensitive data exposure
  • Security misconfigurations
  • Business logic vulnerabilities
  • Privilege escalation
  • Directory traversal
  • Information disclosure

2.3 Out-of-Scope

The following are explicitly out of scope and should not be tested or reported:

  • Social engineering attacks (phishing, vishing, etc.)
  • Physical security attacks
  • Denial of Service (DoS/DDoS) attacks
  • Brute force attacks
  • Spam or abuse of forms
  • Clickjacking on pages without sensitive actions
  • Self-XSS (requires user interaction on own account)
  • Missing security headers without demonstrated impact
  • SSL/TLS configuration issues without proven exploitability
  • Missing cookie flags on non-sensitive cookies
  • Software version disclosure
  • CSRF on logout functionality
  • Presence of autocomplete on forms
  • Username/email enumeration
  • Reports from automated scanners without manual verification
  • Theoretical vulnerabilities without proof of concept
  • Third-party services and applications not under our control
  • Vulnerabilities in outdated browsers or plugins

2.4 Out-of-Scope Assets

  • Third-party hosted services (e.g., Google Analytics, Zendesk)
  • Partner or affiliate websites
  • Development, staging, or test environments unless explicitly authorized

3. Guidelines for Researchers

3.1 Do

  • Test only against accounts you own or have explicit permission to test
  • Stop testing and report immediately if you access sensitive data
  • Provide detailed reports with clear steps to reproduce
  • Allow reasonable time for us to investigate and remediate
  • Communicate through our designated reporting channels
  • Act in good faith and avoid actions that could harm our users or systems
  • Delete any sensitive data obtained during testing
  • Keep vulnerability details confidential until resolved

3.2 Do Not

  • Access, modify, or delete data belonging to other users
  • Perform actions that could degrade or disrupt our services
  • Conduct automated scanning without prior approval
  • Use social engineering techniques against our employees
  • Attempt physical attacks on our facilities or data centers
  • Demand payment or threaten disclosure
  • Publicly disclose vulnerabilities before remediation
  • Engage in any illegal activities
  • Test third-party services integrated with our platform
  • Install backdoors, malware, or persistent access mechanisms

3.3 Testing Accounts

If you need test accounts to conduct security research, please contact us at [email protected] with your research plan. We may provide dedicated test accounts in certain circumstances.

4. How to Report a Vulnerability

4.1 Reporting Channels

Please submit vulnerability reports through one of the following channels:

For encrypted communications, please use our PGP key.

4.2 What to Include

A good vulnerability report should include:

  • Summary: Brief description of the vulnerability
  • Affected Asset: URL, endpoint, or component affected
  • Vulnerability Type: Category of the vulnerability (e.g., XSS, SQLi)
  • Severity Assessment: Your assessment of the impact (Critical/High/Medium/Low)
  • Steps to Reproduce: Detailed, step-by-step instructions
  • Proof of Concept: Screenshots, videos, or code demonstrating the issue
  • Impact: Description of potential damage if exploited
  • Recommendations: Suggested remediation steps (optional)
  • Your Contact Information: For follow-up communication

4.3 Confidentiality

Please do not disclose vulnerability details publicly until we have confirmed remediation. We will coordinate with you on disclosure timelines and, where appropriate, acknowledge your contribution publicly.

5. Our Response

5.1 Response Timeline

We are committed to responding promptly to all vulnerability reports:

Action Timeline
Initial acknowledgment Within 48 hours
Initial assessment Within 5 business days
Status update Every 2 weeks during investigation
Remediation (Critical) Within 7 days
Remediation (High) Within 30 days
Remediation (Medium/Low) Within 90 days

5.2 Our Commitment

When you report a vulnerability in good faith:

  • We will acknowledge your report promptly
  • We will keep you informed of our progress
  • We will work to remediate valid vulnerabilities in a timely manner
  • We will notify you when the issue is resolved
  • We will credit you in our acknowledgments (with your permission)
  • We will not pursue legal action against you for good-faith research

5.3 Severity Ratings

We use the Common Vulnerability Scoring System (CVSS) to assess severity. Final severity determination is at our discretion based on actual impact to our systems and users.

6. Safe Harbor

When conducting security research in accordance with this policy, we consider your research to be:

  • Authorized under the Computer Fraud and Abuse Act (CFAA) and similar laws
  • Authorized under the Digital Millennium Copyright Act (DMCA)
  • Exempt from our Terms of Service restrictions on security testing
  • Lawful, helpful to our security, and conducted in good faith

We will not pursue civil or criminal action against researchers who:

  • Act in good faith and comply with this policy
  • Avoid causing harm to our users, systems, or data
  • Do not violate any applicable laws
  • Report vulnerabilities through designated channels
  • Do not exploit vulnerabilities beyond what is necessary for demonstration

If legal action is initiated by a third party against you for activities conducted in accordance with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Note: This safe harbor does not extend to actions that violate laws, regulations, or that cause harm to ZPHC, its users, or third parties. If you are uncertain whether your research complies with this policy, please contact us before proceeding.

7. Recognition

7.1 Acknowledgments

We value the contributions of security researchers. With your permission, we will publicly acknowledge your contribution on our Security Acknowledgments page.

7.2 Bug Bounty

We currently do not offer monetary rewards...

7.3 Eligibility

To be eligible for recognition or rewards:

  • You must be the first to report the vulnerability
  • The vulnerability must be valid and within scope
  • You must comply with all guidelines in this policy
  • You must not be a current or former employee of ZPHC
  • You must not reside in a country under trade sanctions

7.4 Duplicate Reports

If multiple researchers report the same vulnerability, only the first valid report will be eligible for recognition. We will notify you if your report is a duplicate.

Policy Updates

We may update this policy from time to time. Significant changes will be announced on our website. The "Last Updated" date at the top of this page indicates when the policy was last revised.

Continued participation in our vulnerability disclosure program after changes are posted constitutes acceptance of the updated policy.

Report a Vulnerability

Ready to report a vulnerability?

Submit a Report