Reporting a vulnerability.

What we commit to

• We will not pursue legal action for good-faith research conducted within the boundaries below.
• We will acknowledge your report and tell you what we found, including if we disagree that it is a vulnerability.
• We will credit you if you want credit, and not if you do not.

What we ask

• Test against your own account and your own domains. Not another customer's data, and not a third-party site through our scanner.
• Do not degrade the service. No load testing, no denial of service, no mass automated scanning.
• Do not exfiltrate data. Demonstrate access; do not collect. If you encounter someone else's data, stop and tell us.
• Give us time to fix it before publishing.

What we are most interested in

The unauthenticated scan surface is the part a stranger can reach, so it is where a flaw costs the most:

• The SSRF guard. Anything that gets our fetcher to reach an address it should refuse: private space, cloud metadata endpoints, redirect chains that escape validation.
• The verification path. Anything that submits a scan without solving the challenge, or that turns the endpoint into a probe for whether a hostname resolves internally.
• The email gate. Anything that returns findings for a scan whose address was never verified, or that exposes them through a share link.
• Token handling. Verification tokens are stored hashed; anything that recovers or replays one.
• Tenancy boundaries. Anything that reads one brand's data from another's session.

Out of scope

• Missing security headers with no demonstrated impact.
• Rate limits being generous. They are deliberately not the primary control.
• Reports generated by an automated scanner with no verification or proof of exploitability.
• Social engineering of our people or our vendors.

Bounties None offered

There is no bug-bounty programme and no payment. Saying so plainly is fairer than letting a researcher assume otherwise and invoice afterwards.

How to report

Email security@crawld.co with steps to reproduce, what you were able to access, and what you did not do. Include a requestId from any response envelope if one is relevant.

Security practices Usage policy