August 8, 2017

If you believe you have found a security vulnerability in Legal Robot, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. As long as your research stays within the bounds of this policy, we welcome the dialog, promise not to take legal action, and hope that we can compensate you for your efforts to make our products more secure.

It is our policy to request at least limited disclosure on all Resolved reports, but we’ll work with you if there is a legitimate reason to delay disclosure. Also, because we want to show that we respect your work, we will only close a report as a Duplicate with a link to the original report or to a previous public disclosure.


  • Use good judgment. If you find a vulnerability, don’t run it in production. Instead, use our non-production environment at
  • Again, don’t run tests against our production domain,
  • Do not destroy or degrade our performance, or violate the privacy or integrity of users or their data.
  • Never attempt to view, modify, or damage data belonging to others in production (do this on
  • Do not interact with other users.
  • Do not attempt a denial-of-service attack.
  • Do not perform any research or testing in violation of law.
  • Please don’t ask for updates on a report.

Helpful Hints

  • Our www subdomain is all static content, focus on the app subdomain.
  • Bounties for access to other users’ data are worth the most. DO NOT ATTEMPT THIS IN PRODUCTION.
  • We don’t use cookie-based authentication.
  • We primarily use NoSQL databases. Try NoSQL injection attacks before SQL injection.
  • We use Stripe as our payment processor. See the testing documentation for test credit card numbers that will result in a successful transaction in our non-production environment.
  • Disputing a live Credit Card transaction will get you immediately banned and no longer exempted from legal action.
  • It’s easier for us to research issues when you include the version number and build in your report (check the bottom left corner in our non-production environment).
  • When possible, we post about unresolved bugs here: Check the “Known Issues” section before submitting a report.

Destructive/Invasive Attacks

All of the data in our non-production environment ( is non-sensitive, so have at it… just DO NOT do anything illegal, or launch an extended denial-of-service or similar attack that could disrupt or get us blacklisted with our service providers. Because is not a full production environment, DMARC, SPF, and similar email issues will not be eligible there. Issues that we cannot reproduce in production ( will not be accepted.

Ineligible Reports

  • Anything from an automated scan, anything that is already public, or anything not under our control.
  • Version disclosure, unless it leads to a vulnerability.
  • Anything that requires physical access to a device or network, special permissions (e.g. tapjacking), rootkits, etc.
  • Anything requiring outdated browsers, platforms, or crypto (i.e. TLS BEAST, POODLE, etc).
  • Social engineering, phishing, spear phishing, etc.
  • Header injection, unless you can show how they can lead to stealing user data.
  • Login/logout CSRF, or lack of CSRF tokens.


For any questions or clarification on this policy, feel free to email us at [email protected] or ask us inside the app through the Intercom chat window (bottom right corner when logged in).

Thanks & Compensation

We believe in recognizing the work of others. If your work helps us improve the security of our service, we will happily acknowledge your contribution. We also offer a monetary bounty of $20-$???? for legitimate, non-duplicate security issues reported through HackerOne, provided you follow these rules. More serious issues will be rewarded appropriately.


  The text of this page is released into the Public Domain under the Creative Commons Zero license.