How-to guides
Report a security issue
How to report a vulnerability in HumanRisk Shield, what is in scope, and when you will hear back.
If you think you have found a security weakness in HumanRisk Shield, email security@humanriskshield.com. A person reads every report. Good-faith research that follows the vulnerability disclosure policy is authorized, and HRS will not take legal action over it.
This page is for flaws in HRS itself. To report a phishing email you received at work, use your organization's report button instead: see Report a suspicious email.
What to put in the report
- The address, endpoint or part of the product affected.
- Steps to reproduce it, in enough detail to follow.
- What an attacker could actually do with it.
- Any proof of concept, screenshots, or request and response pairs.
- How you would like to be credited, if at all.
Send one issue per email, in English where you can. Leave out other people's personal data.
What happens next
| Stage | Target |
|---|---|
| A person acknowledges your report | 2 working days |
| First assessment of severity and scope | 5 working days |
| Progress updates | at least every 10 working days |
| Fix | 30 days for critical and high, 90 days for the rest |
If a fix needs longer, you will be told why. Please allow a reasonable window before you publish. Credit is given on resolution if you want it. There is no paid bug bounty.
In scope
- humanriskshield.com and its subdomains, including learn.humanriskshield.com and exposure.humanriskshield.com
- The public APIs and any endpoint they call
- Sign-in, sessions and the separation between customer organizations
- Anything that exposes another customer's data
Out of scope
- Denial of service, load testing and bulk automated scanning
- Phishing or other social engineering of HRS staff, customers or suppliers
- Physical attacks
- Services HRS uses but does not run, unless the problem is in how HRS configured them
- Reading or changing data that is not yours
Reports that are usually closed
Missing headers or email records with no real impact, self-XSS, clickjacking on pages that change nothing, rate limits on public pages that hold nothing sensitive, unvalidated scanner output, version numbers without an exploit, and problems that only affect browsers no longer receiving updates. Show a real impact and they will be looked at again.
The machine-readable contact is at /.well-known/security.txt.