Whilst I can't fault the idea of Bug Bounties, there is some evidence coming through that they many sites on such programmes retain significant bugs even after a substantive period. So I would say get an application security testing company to make recommendations first and implement them (Declaration I don't work for one, although I do security test web applications).

Also Bug Bounties typically exclude things like social engineering, and process failings in organisations. You may well have these covered elsewhere, but business processes should be a "before anything else" item.

My pet hate:

Bug bounties that exclude lots of issues that the site owner hasn't cleaned up.

The classic is HTTP related security headers (think CSP, HSTS), or cookie flags, kind of thing covered by securityheaders.io or Hardenize, or Immuniweb. Also the kind of thing Burp-Suite spits out in the first few milliseconds of a scan.

 meta.stackexchange.com gets a C at Immuniweb 

 meta.stackechange.com gets an F at securityheaders.io

 Hardenize has some suggestions (DNSSEC), but doesn't really help much.

These are important defences, the bug bounties typically exclude them as they permit of automated reporting, and typically fall under best practice rather than a specific vulnerability. So either there is no reporting, or no reward for reporting these holes, so they go unreported.

For example you do Strict-Transport-Security (with a short max-age!!!) on meta.stackexchange.com, but you don't include subdomains, so if an attacker has access to the network he can create "hackme.meta.stackexchange.com" (because DNS is usually unsecured, yours definitely is) and have access to the end-user's cookies (which incidentally all lack the secure flag so are all game for being stolen this way when Strict Transport Security is not in effect).

Typically Bug Bounties exclude a report like this. This isn't a fault of the bug bounty programme, but perhaps something to understand about them before you get started.

So quite often I see sites on Bug Bounty programmes where I can break the protection TLS is suppose to provide, but I end up reporting it via support rather than the bug bounty programme, because the bounty programmes want clever and original, when 'simple' hasn't been done. Or there are a bunch of good practices being omitted, again typically excluded from bug bounty programmes.

When in doubt copy what github.com have done. GitHub even have a really good [blog][1] about it.

Apologies for the "how to hack meta.stackexchange.com user's cookies" bit, but anyone who is capable didn't need the hint, as they already know how to do this sort of thing.


  [1]: https://githubengineering.com/githubs-bug-bounty-workflow/