1. Scope — what’s in for testing
Hushward stores sensitive personal information on behalf of our users to run data-removal work on their behalf. The following surfaces are in scope for responsible testing:
- Account records. Names, email addresses, phone numbers, account credentials, and the authentication cookies that gate access to a workspace.
- Scan inputs.Past addresses, aliases (including historical or alternative names), date of birth, and any sensitive identifiers a user supplies — such as SSN-type fields used to verify identity with a broker.
- Opt-out signatures. E-signatures and recorded consent artifacts produced when we file a removal or opt-out request on a user’s behalf.
- Cross-user isolation. Anything that touches the boundary between one user’s workspace and another’s — authentication, authorization, and per-user query enforcement are first-class targets.
2. Scope — what’s out
The findings below don’t qualify for the commitments in section 6. We list them so the line is unambiguous.
We won’t accept
- UI or UX defects: cosmetic typos, missing rate-limit on a benign endpoint, banner or menu bugs.
- Volumetric denial-of-service of any kind.
- Physical attacks against our infrastructure, offices, or staff.
- Social engineering of staff or users. The Contact Us mailbox is for product tips and customer support — it is not a credential-checking channel.
- Disclosures of issues we’ve already identified and ticketed publicly in our changelog.
- Findings against third-party domains we only host through (Stripe, our CDN, our authentication provider). Please disclose those directly to the vendor.
Please don’t
- Run automated scanners or bulk traffic against us.
- Perform denial-of-service testing, even of single endpoints.
- Exfiltrate data belonging to another customer — even if a finding allows you to browse it. STOP. Email us instead, and delete anything you accessed.
- Social-engineer staff or users; harvest credentials; or phish.
- Test against production if a non-production equivalent is available — ask us for a sandbox.
3. How to report
Send your report by email to Contact Us. That mailbox is monitored by the security team and is the only channel we commit to for triage timelines below. If the address needs to change for any reason, a notice will appear on this page and in our customer-update mailing list before the change takes effect.
What to include. The URL or affected component, step-by-step reproduction, the impact you observed, and (for HTTP findings) the request and response with the Authorization header redacted. Include your name and a handle if you’d like credit per section 7.
Encryption. If you prefer an encrypted channel, email us first at Contact Us and we’ll reply with instructions for a key exchange. We do not publish a long-lived PGP fingerprint on this page.
Attachments.Plain-text writeups are preferred. If you need to share a binary, send a link to a download we can fetch — please do not email executables.
4. Our commitments — what we’ll do
- Acknowledgement within 3 business days. You’ll hear from a human confirming we received the report and naming the engineer who owns the triage.
- Triage and severity rating within 10 business days. We’ll share a CVSS-style severity rating and our initial assessment of impact. We won’t communicate in customer-impacting language during the active window.
- Status updates every 14 days. Until the report is resolved — either by a fix, a documented decision not to fix, or a coordinated disclosure.
- Credit, on request. Researchers who help us are listed on our public acknowledgement page using the handle they provide — unless they ask to remain anonymous.
- No law enforcement or civil counter-claims. See sections 6 and 8.
5. Coordinated disclosure
We follow a 90-day coordinated-disclosure window from the date we acknowledge a report. That gives us a standard amount of time to develop, review, and ship a fix; if a fix turns out to need upstream coordination, we’ll negotiate a longer window with you in writing — we don’t enforce the 90-day line against a researcher who is actively working with us.
If we don’t resolve the report within the agreed window, public disclosure is acceptable. If we do ship a fix, we publish a postmortem after the fix lands, citing you by handle (or anonymously, per your request).
6. Safe harbor
We consider research conducted under this policy to be authorized for the purposes of avoiding violations of the Computer Fraud and Abuse Act, the Digital Millennium Copyright Act (anti-circumvention provisions), the EU Computer Misuse Directives, and similar computer-misuse or unauthorized-access laws in the jurisdictions where we operate.
We will not pursue civil action or refer for criminal prosecution any researcher who:
- Acts in good faith and follows this policy in letter and spirit.
- Stays within the scope of section 1 and does not exceed it.
- Exfiltrates no more data than is necessary to demonstrate the finding, deletes any data accessed in the course of the test, and does not retain or share copies after resolution.
- Does not violate any law outside the scope of this authorization — for example, the law against unauthorized access is preserved where it applies, and we grant authorization only for the testing described here.
- Makes a good-faith effort not to disrupt service. Brief, necessary tests that produce momentary outages during off-peak hours are acceptable; sustained interruption or data loss is not.
This safe-harbor commitment extends to research performed against our staging and sandbox environments where we provide access in response to a request, as well as against our production endpoints within scope.
7. Recognition
We maintain a public acknowledgement list of researchers who have helped us ship safer software. If you’d rather not be named, we’ll honor that — just say so in your report.
Hushward does not run a paid bug-bounty program today. The program is a researcher-recognition program: the reward is credit, a postmortem citation, and the legal comfort of section 6. If we introduce financial rewards in the future, this policy will be updated and active contributors will be notified.
8. Changes to this policy
When we make material changes to this policy, we’ll notify active account holders by email and update the effective date at the top of this page. Non-material edits — clarifications, wording, or contact updates — are reflected in the change history without a separate notice. Open reports at the time of a material change continue under the version of the policy you reported under.
9. Contact
Anything else? Email Contact Us. Press and media inquiries about a disclosure go through Contact Us — please don’t send vulnerability details to the press inbox.