If an application's code contains even minor and subtle inaccuracies, it can open up the entire database to SQL injection. In this example (see section 'Delete All Method'), the entire Users table gets deleted with a trivial SQL injection ("1) OR 1=1--").

This had me wondering, have any white hats / bounty hunters (perhaps amateurs) looked for vulnerabilities and accidentally caused massive, real damage to the site/app/business? How do bounty programs deal with such a risk?

  • 46
    If you destroy somebody's database while looking for vulnerabilities, I'm not sure you can be called a white hat. Commented Jan 26, 2021 at 17:13
  • 2
    What would you consider real damage to a site/app/business? Commented Jan 26, 2021 at 19:36
  • 18
    @stevec Thanks for the clarification. As a former pentester, I can tell you that unintentional accidents do happened, because something was misconfigured on a client system that lead to either degrading performance or even a full crash. Commented Jan 27, 2021 at 1:22
  • 4
    @stevec In case you didn't notice my edit summary: If you're not happy with the changed focus of the question, feel free to re-edit or switch it back. Maybe you're happier with the previous version given that you're mostly after a concrete example.
    – Arminius
    Commented Jan 27, 2021 at 2:21
  • 5
    @Arminius I noticed and appreciate it. It is now much more useful and substantive while still being very interesting to learn about (the latter - curiosity - was my primary motivation, and 'learning from past mistakes' the secondary). Thanks for the improvement
    – stevec
    Commented Jan 27, 2021 at 2:26

3 Answers 3


Can bounty hunting cause real damage?

Sure. As you pointed out, some SQL injection vectors may inadvertently cause data deletion. Similarly, a persistent XSS attack may trigger in the browser of a real user. Or unusual characters in a username may crash a web application backend due to an unhandled encoding error.

More generally, a large part of black box pentesting involves experimenting with unexpected/invalid input to the target application. Some level of fuzzing is usually unavoidable - and this always carries the risk of causing behavior that breaks the application or corrupts data. So, while blindly trying out DELETE queries may be reckless and avoidable, vendors have to face that even benign bug hunting occasionally impacts service integrity or availability.

Did a bounty hunter ever cause actual damage?

This report is an example of where the researcher caused a DOS by submitting invalid data. I'm entirely sure there are more severe examples, many of which simply weren't made public. Anecdotally, I remember several occasions where bug hunters were banned from programs because the tools they used were too disruptive.

How do bug bounty programs manage this risk?

  • A testing environment. While some bug bounties assume you're testing against production, many provide a separate sandbox and only allow you to test there. E.g., the program of Bitmex includes the rule:

    Only test on testnet.bitmex.com.

  • A "responsible research" policy which asks that hunters make an effort to avoid damage. Rules would include not accessing real user data, limiting automated testing tools, etc. For example, Facebook's program demands:

    You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) unauthorized access to or destruction of data, and interruption or degradation of our services. You must not intentionally violate any applicable laws or regulations, including (but not limited to) laws and regulations prohibiting the unauthorized access to data.

  • An emergency contact point. Some providers instruct hunters how to notify them immediately if their actions have caused service disruption. From the program of Exodus:

    If you do accidentally cause some noticeable interruption of service, please immediately email us so we can handle it accordingly [email protected] and please include the subject title "HackerOne Outage: " for the alert to trigger.

Safe harbor clauses protect participants

Nowadays, many program policies come with a safe harbor clause. This is intended to protect hunters from liability if they act in good faith, even if their actions have caused damage. Since IANAL, I can't comment on the effectiveness of such a policy, but it's an established practice. Here is an example of a safe harbor clause in the program of Dropbox:

We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. We consider activities conducted consistent with this policy to constitute “authorized” conduct under the Computer Fraud and Abuse Act. To the extent your activities are inconsistent with certain restrictions in our Acceptable Use Policy, we waive those restrictions for the limited purpose of permitting security research under this policy. We will not bring a DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope.

You'll find a similar passage in the rules of most large programs.

  • 4
    And I'd say the vendor has a responsibility to have backups and redundancy in place anyway. Just because they hired a pentester to find bugs, doesn't mean they shouldn't be prepared for them to be triggered and cause damage. Indeed, quite the opposite: you're literally asking someone to try to do that. Commented Jan 28, 2021 at 14:00
  • 23
    This answer is a clinic for answers: concise but detailed, thought out, cites sources, addresses the multiple components of the question, and breaks those components down into readable sections. Very nice
    – Ivan G.
    Commented Jan 28, 2021 at 15:57
  • 10
    @IvanG.: And just the right amount of headline / bold to make skimming possible. Commented Jan 29, 2021 at 0:59

Your question appears to assume that the attacker in question is working against a production system. To Fire Quacker's point, if you break someone's production system you're just as liable as any other attacker regardless of your white hat intentions (assuming it is not allowed as a part of a bug bounty program). And this is why bug bounty programs should set up special instances for testing that are not in production.

  • 8
    Note that the question technically asks "has this ever happened?". You've answered a more useful question, IMO, so I'm not actually complaining, but it may not hurt to also try to answer the question as it was asked. Commented Jan 26, 2021 at 18:02
  • 10
    I'm pretty sure that all bug bounty programs are for production systems. Pentesting is typically against pre-production or test systems.
    – schroeder
    Commented Jan 26, 2021 at 19:59
  • 5
    @schroeder Many newer programs provide a separate testing environment and restrict bounty hunting to that one. That's often the case with sites that have a public non-production site anyway, like crypto trading sites. I have an example in my answer.
    – Arminius
    Commented Jan 26, 2021 at 22:39

Robust systems should not only resist attacks but demonstrate viable recovery mechanisms. The cost of bugs may be less than bad design. Do you have logs? Can you use them to recover quickly? Production systems may have vulnerabilities like DOS that test systems lack!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .