Plain-English Summary
This summary is provided for convenience only. It does not replace or override the full policy below.
- Found a security bug? Email us privately before telling anyone else — we take reports seriously.
- Include enough detail for us to reproduce it: the affected URL, the type of issue, and numbered steps.
- Don't access other people's data, break the service, or run destructive or volumetric tests.
- We acknowledge, investigate, fix by severity, and follow up when the fix ships. Good-faith researchers acting within this policy won't face legal action from us.
- This is a disclosure policy, not a bug bounty — payment is not guaranteed.
We appreciate responsible security research that helps protect HelloGrowthCRM customers. If you believe you have found a security vulnerability, please report it to us privately before public disclosure.
How to report
Email sales@hellogrowthcrm.com with the subject line "Security vulnerability" and include a clear description, steps to reproduce, affected URLs or components, and any proof-of-concept you are comfortable sharing. Encrypt sensitive details if your organization requires it; mention that in the message and we will coordinate a secure channel if needed.
Scope
Reports should concern the HelloGrowthCRM product, APIs, and official web properties operated by Soor LLC. Do not access data that does not belong to you, degrade production services, or perform destructive testing without prior agreement.
What to expect
We aim to acknowledge valid reports promptly, investigate in good faith, and remediate serious issues according to severity. We may credit researchers when a fix ships if you would like public recognition. This page does not constitute a bug bounty program or guaranteed payment; commercial bounty terms, if offered, will be published separately.
What makes a strong report
The fastest path to remediation is a report we can reproduce. Strong reports include: the exact URL, endpoint, or component affected; the type of issue (for example XSS, IDOR, authentication bypass, injection); numbered reproduction steps from a clean session; the impact you believe an attacker could achieve; and any relevant request/response captures or screenshots. One issue per report helps us triage accurately. Reports generated solely by automated scanners without a demonstrated impact are usually not actionable.
Out of scope
The following are generally not accepted as vulnerabilities unless you can demonstrate a concrete security impact: missing security headers or cookie flags on non-sensitive pages; SPF, DKIM, or DMARC configuration observations; clickjacking on pages with no sensitive actions; rate-limiting observations without a demonstrated abuse path; version disclosure without an exploitable weakness; social engineering of our staff or customers; physical attacks; and denial-of-service or volumetric testing, which is never authorized.
Our response process
After you submit a report we (1) acknowledge receipt, (2) triage and attempt to reproduce the issue, (3) assess severity based on impact and exploitability, (4) remediate according to that severity, and (5) follow up with you when a fix has shipped. We ask that you allow a reasonable remediation window before any public disclosure and that you coordinate the disclosure timing with us; we are glad to agree on dates in writing for significant findings.
Good-faith research
We will not pursue legal action against researchers who act in good faith within this policy: accessing only the minimum data necessary to demonstrate the issue, not disrupting the Service or other customers, not exfiltrating, modifying, or destroying data, and reporting the finding promptly and privately. If you are unsure whether an activity is in scope, ask first via the reporting address above.
Key terms explained
For reporters who are not full-time security professionals, the terms used above mean:
- Vulnerability:a weakness in software or configuration that an attacker could use to do something the system should not allow — reading someone else's data, bypassing a login, running code.
- XSS (cross-site scripting):injecting script into a page so it runs in another user's browser, typically to steal sessions or perform actions as that user.
- IDOR (insecure direct object reference): changing an ID in a URL or request and receiving data that belongs to a different user or account.
- Proof-of-concept: a minimal demonstration — steps, a script, or a screenshot — showing the issue is real and what impact it has.
- Coordinated disclosure: the practice of giving the vendor time to fix an issue before any public write-up, with timing agreed between researcher and vendor.
- Remediation window: the period we ask you to wait, after reporting, while we ship a fix.
Related pages
For general security and compliance documentation, see the security overview and the Trust Center. Rules on what customers may and may not do with the Service, including security testing, are in the Acceptable Use Policy. How we handle personal data is covered in the Privacy Policy.