December 31, 2016

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. However, some of our products are in beta, so we do expect a large volume of changes in our code and may already be aware of the issue. If you submit a report for a known issue, we will do our best to let you know quickly so you can move on.


In the words of Cesar Millan: “no talk, no touch, no eye contact”. Basically, use good judgment (except as outlined below in “Destructive/Invasive Attacks”).

  • Clearly identify your account by adding something like “H1”, “attacker”, “hacker”, “test”, etc. to your name so we don’t terminate your account when we see suspicious activity.
  • Do not destroy or degrade the performance of our products and services, or violate the privacy and integrity of user accounts and data.
  • To be clear, you must never attempt to view, modify, or damage data belonging to others in production (though, we encourage these attempts in our non-production environment).
  • Do not interact with other users without their prior consent.
  • Do not attempt a denial-of-service attack on our production environment (
  • Do not perform any research or testing in violation of law.

As long as your research stays within the bounds of the criteria in this policy, we welcome the dialogue and promise not to take legal action.

Report Focus & Tips

We are particularly interested in problems that allow unauthorized access to other user’s documents and will award monetary bounties accordingly. However, YOU MUST ONLY ATTEMPT THIS IN OUR NON-PRODUCTION ENVIRONMENT (

Our www subdomain only hosts static, non-sensitive content like our blog and marketing pages, so many attacks against this subdomain are unlikely to result in a bounty. We suggest that you focus your efforts on our app subdomain.

We proudly use Stripe as our payment processor. To simulate a payment and gain access to a paid-only section of our app, we suggest you work in our non-production environment ( and check out the Stripe testing documentation which has test credit card numbers.

If you accidentally perform a live transaction, just let us know at [email protected] and we’ll make things right. Security researchers that dispute a live transaction will be immediately banned from our HackerOne program and will no longer be exempted from legal action. We may take further action outside of this policy (but always in accordance with our terms of service).

Destructive/Invasive Attacks

We provide a non-production environment ( that you may use for destructive and invasive attacks. All of the data in this 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 (keep any DoS attempts short… like, under a few minutes). Because is not a full production environment, DMARC, SPF, and similar email issues will not be eligible. To be clear, issues that exist on the domain but not on will not be accepted.

Ineligible Reports

  • Reports from automated tools or scans
  • Already public issues related to software, scripts, or protocols not under our control (e.g. meteor.js, node.js, cordova, etc)… unless we are using a version that is seriously out of date
  • Security issues in 3rd party components (Disqus, Intercom, Stripe), unless they present a unique threat to our service. Usually, these issues should be reported to the company that makes the component. We’re more than happy to hear about these issues, but they will not be eligible for a bounty (reputation only).
  • Use of a known-vulnerable library without evidence of exploitability
  • Disclosure of software version, server IP, or other non-sensitive information. We’re happy to accept reports on this, but reports will be closed as informative without a demonstration of an exploit using the information.
  • Attacks requiring physical access to a user’s device or network
  • Attacks that require attacker app to have the permission to overlay on top of our app (e.g., tapjacking)
  • Any access to data where the targeted user needs to be operating a rooted mobile device
  • Vulnerabilities affecting users of outdated browsers, platforms, or crypto (i.e. TLS BEAST, POODLE, etc)
  • Social engineering of our staff or contractors, phishing, spear phishing, etc.
  • Any physical attempts against our property or our host’s data centers
  • Presence of autocomplete attribute on web forms
  • Missing public key pins
  • Missing best practices (we require evidence of a security vulnerability)
  • Missing cookie flags on non-sensitive cookies (we don’t use cookie-based auth)
  • Host header injections unless you can show how they can lead to stealing user data.
  • Reports of spam (i.e. any report involving ability to send emails without rate limits)
  • Lack of CSRF tokens (unless there is evidence of actual, sensitive user action not protected by a token)
  • Login/logout CSRF
  • [Temporary] New reports of missing rate-limiting on Meteor methods. We recognize this is a problem and we’re currently working our way through several hundred method calls.
  • [Temporary] New reports of authorization bypass on sensitive methods. We recognize this is a problem and we’re currently working our way through a couple dozen sensitive method calls.

You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the issue to be more extensive.


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). All security reports must be performed through HackerOne so we can track reports and compensate you.

Thanks & Compensation

We believe in recognizing the work of others. If your work helps us improve the security of our service, we’d be happy to acknowledge your contribution. In addition to showing our appreciation for our security researchers, we also offer a monetary bounty for security issues, provided you follow the rules. More serious issues will be rewarded appropriately. Many researchers find similar or identical issues at the same time so unfortunately, duplicate issues will only receive our appreciation.


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