Responsible Disclosure Policy

Summary

We take security seriously. If you find a vulnerability in Pherox, please tell us at team@pherox.co.uk with "Security" at the start of the subject line.

Safe-harbour: if you report a security issue to us in good faith, stay within the scope below, and give us reasonable time to fix it, we will not pursue legal action against you. We treat your report confidentially.

Response: we acknowledge within 5 business days. We aim to give you an initial assessment within 14 days.

Recognition: no cash bug bounty at launch. We maintain a security researcher acknowledgement section (when we have something to publish) and we are happy to credit researchers there if they want recognition.

1. Safe-harbour: what it is and what it does

If you find what you think is a security vulnerability in Pherox, please report it to us in line with this policy.

Our commitment to you (the safe-harbour):

If you report a vulnerability to us in good faith, and you:

• Stay within the scope set out in section 2
• Do not engage in any of the prohibited activities in section 3
• Do not publicly disclose the vulnerability before we have had reasonable time to fix it (see section 6)
• Provide a clear, honest report

then we will not bring or support legal action against you under the Computer Misuse Act 1990, the Police and Justice Act 2006, our Terms of Service, our Acceptable Use Policy, or any other legal basis we might otherwise rely on for the access or testing you needed to do to find the issue.

This safe-harbour is our commitment. We mean it.

What it does not cover:

• Actions against other people's rights. If your testing causes you to access another user's personal data, you have done something we cannot grant safe-harbour for. The other user's rights are not ours to waive.
• Third-party services. We can only grant safe-harbour for our own systems. If you find an issue in Stripe, Cloudflare, or any other sub-processor, contact them directly (see section 2).
• Bad faith. If you exploit a vulnerability for personal gain, hold it for ransom, threaten public disclosure to extract concessions, or otherwise act in bad faith, this policy does not protect you.

2. Scope

In scope

The following systems are in scope for this policy:

• The Pherox marketing website at pherox.co.uk and any subdomains we own (not including subdomains operated by third parties on our behalf)
• The Pherox application at app.pherox.co.uk
• The Pherox API endpoints, when public
• Pherox-authored client-side code (JavaScript, web components, future mobile apps)
• Pherox PDF generation (vulnerabilities in the PDFs we generate)

Out of scope

The following are out of scope. We cannot grant safe-harbour for testing them and we ask that you do not include them in your report:

• Third-party services we rely on but do not control:
  • Stripe (report via stripe.com/security)
  • Cloudflare (report via hackerone.com/cloudflare)
  • Google (report via google.com/about/appsecurity)
  • Microsoft (report via msrc.microsoft.com)
  • All other sub-processors listed at pherox.co.uk/sub-processors
• Pherox staff personal devices, accounts, or social media
• Findings purely based on outdated browser warnings, missing security headers without demonstrated impact, or theoretical vulnerabilities without a clear exploit path
• Findings purely based on weak or absent rate limits without demonstrated business-logic impact
• Findings based on automated scanner output without manual validation
• "Self-XSS" (XSS that requires the victim to attack themselves, e.g. by pasting payloads into their own browser console)
• Issues affecting unsupported browsers or browser versions (we support current versions of Chrome, Safari, Firefox, Edge)

3. Permitted and prohibited activities

What you can do

• Look for vulnerabilities using your own account
• Look for vulnerabilities by inspecting publicly accessible pages, JavaScript, network traffic
• Do non-destructive testing that is necessary to identify and verify a vulnerability
• Demonstrate impact with the minimum necessary proof-of-concept

What you must not do

• Do not access, modify, copy, exfiltrate, or destroy data that is not your own, beyond what is strictly necessary to verify the vulnerability exists
• Do not test using or against another user's account or data
• Do not run automated scans, fuzzers, or load tests against production at a rate that materially degrades service for other users
• Do not perform denial-of-service or distributed-denial-of-service testing
• Do not use social engineering (phishing, pretext calls, in-person tactics) against Pherox staff
• Do not attempt physical access to Pherox staff, offices, or infrastructure
• Do not spam or phish Pherox users
• Do not attempt to take or hold data for ransom
• Do not publish details of a vulnerability before we have had reasonable time to address it (see section 6)
• Do not violate any law in your testing

If you are unsure whether something you want to do is in scope, email us first at team@pherox.co.uk with "Security: scope question" in the subject line. We will respond within 5 business days.

4. How to report a vulnerability

Email team@pherox.co.uk with "Security" at the start of the subject line. Include:

• A clear description of the vulnerability
• The affected URL(s) or component(s)
• Step-by-step reproduction instructions
• The impact (what could an attacker actually do)
• The proof-of-concept (the minimum needed to demonstrate the issue)
• The date and time of your testing (so we can correlate with logs)
• Your name (or pseudonym) and contact email
• (Optional) whether you would like to be credited if we publish acknowledgements (see section 7)

We do not currently accept reports via Twitter, LinkedIn, Reddit, GitHub Issues, or other public channels. Email keeps things confidential and creates a clear audit trail.

If you have a PGP key and want to encrypt your report, tell us in your first message and we will agree on a key exchange. We do not currently publish a Pherox PGP key.

5. What we will do

When we receive your report:

Step 1: Acknowledge (within 5 business days). We confirm we have your report, give it a reference number, and ask any clarifying questions.

Step 2: Triage and assess (within 14 days). We investigate, reproduce the issue, and assess severity. We tell you what we have decided: whether we agree it is a vulnerability, our assessment of the severity, and our intended response.

Step 3: Fix. We work on the fix. Timing depends on the severity:

• Critical (active exploitation or imminent risk): we aim for a fix within 24 to 72 hours
• High (significant impact, exploitable): we aim for a fix within 7 to 14 days
• Medium: we aim for a fix within 30 to 60 days
• Low or informational: as part of normal product work, no specific SLA

We may agree a different timeline with you if the issue is complex.

Step 4: Verify. Where appropriate, we ask you to verify the fix.

Step 5: Close and (where you have agreed) credit. We close the case, thank you, and where you have asked for credit, we plan how to publish acknowledgement (see section 7).

6. Coordinated disclosure

We follow a coordinated disclosure model.

Default disclosure window: 90 days from the date you report the issue to us.

• Within this window, you agree not to publish details of the vulnerability publicly.
• We commit to working with you in good faith to fix the issue within this window.
• If we need more time on a complex issue, we will tell you why and propose a revised timeline, agreed with you.
• If we have not fixed the issue within the agreed window and have not requested an extension, you are free to disclose publicly. We ask that you tell us before you do.

For critical issues that are being actively exploited, the disclosure window may need to be tightened, including immediate emergency disclosure to affected users. We will discuss this with you if it arises.

We do not retaliate against researchers who publish after the agreed window. The agreement is on us to fix within the window or to negotiate an extension; if we miss both, the responsibility is ours.

7. Recognition

We do not currently run a paid bug bounty programme. As we scale, we may. We will update this policy if and when we do.

We maintain a public Security Researcher Acknowledgement section on this page (added below as researchers contribute). With your permission, we credit researchers whose reports we have acted on. Credit is by your preferred name or pseudonym; we do not publish your contact details.

You do not have to accept credit. If you would prefer to remain anonymous, tell us in your report.

8. What we will not do

• We will not pursue legal action against good-faith researchers acting within this policy (section 1)
• We will not share your identity or your report with third parties beyond what is necessary to investigate and fix the issue
• We will not disclose unfixed vulnerabilities to anyone who does not need to know
• We will not retaliate against your Pherox account if you are also a user
• We will not require you to sign an NDA or other agreement before we will hear your report

9. If we disagree with your assessment

Sometimes we will assess a report and decide we do not agree that it represents a vulnerability, or that the severity is lower than you believe.

If we disagree:

• We tell you why, in plain English
• You are free to ask us to reconsider, with additional information or context
• If we still disagree after reconsidering, we close the report and the safe-harbour still applies to your conduct in making the report
• You retain your right to publicly disclose, subject to the coordinated-disclosure window in section 6

Disagreement does not void the safe-harbour for actions taken in good faith within scope before the disagreement.

10. Changes to this policy

We may update this policy from time to time. Material changes (for example a change to scope, the safe-harbour, or disclosure timelines) take effect 30 days after publication and we update the security.txt Expires field accordingly.

Non-material changes (clarifications, contact-detail updates) take effect immediately. We note the change date below.

11. How to contact us

Vulnerability report: team@pherox.co.uk with "Security" at the start of the subject line

Scope question before testing: team@pherox.co.uk with "Security: scope question" in the subject line

General security question (non-vulnerability): team@pherox.co.uk

Post: Pherox Technologies Ltd, 195 Manchester Road, London E14 3DR

Security Researcher Acknowledgement

We are grateful to the researchers who help us keep Pherox safe.

No acknowledgements yet. Be the first.