As the popularity of my services like and has increased they've started to attract more attention. Most of this is good but I've recently started to experience something a little concerning.

Bug bounties

I want to start off by saying that I think bug bounties are a great thing. The adoption of bug bounties not only helps the organisation in question by gaining them exposure to large numbers of ethical researchers but they are also helping to shift perceptions in the industry. Security researchers have traditionally had very bad experiences dealing with companies when disclosing security vulnerabilities, I know from experience, but this is changing. Both and have bounty programs setup on HackerOne and whilst they're not public just yet, they soon will be. People that have raised issues through these programs have never had an expectation of financial reward (they're both free services so there's no budget for bounties sadly) and I've had good dealings with those that I've interacted with. Fortunately I've not had any serious problems yet but there have been some good practice and minor findings. Good stuff aside, there are a couple of things that haven't been so great over the last few months.


Both via HackerOne and raised directly via email I've had some very serious, critical rated, (non) issues raised in both the and sites. My favourite of these is always SSRF, which I will detail below, but there are others too.

Server-Side Request Forgery

SSRF is where an attacker can force a server to issue HTTP requests. Typically a compromised web server may be used to issue requests against other, internal, servers at the organisation. SSRF is indeed a legitimate issue in certain scenarios but that's the key point to make here, "in certain scenarios". Context is hugely important here and when you consider what the very purpose of is, having the ability to get my server to execute 'arbitrary' HTTP requests is kind of the entire point of the service. There was no ability to issue requests at private or internal IP addresses, everything like that is filtered, this was straight up HTTP requests issued to other internet hosts. Getting bug reports like this is really annoying for 2 reasons. 1, it shows that the bug hunter hasn't so much as even looked at the site and what it's purpose is. A lot of the time I feel they've just run some basic, automated tool against the site and copy/pasted the findings into bug reports without so much as a single thought about whether it's a false positive or not. That leads directly into reason number 2 that these are really annoying, they're a huge waste of time. You can't just close issues like these without providing a reason or explanation as this makes most people really unhappy, and I get that. But when they haven't even taken the time to think about the bug they're raising and you now have to spend time responding, it does start to grate, especially when they want to argue about why it is an issue! Across and the various tools on that issue HTTP requests for analysis, this is a common 'finding'.

Repeated issues

On a similar thread to above, another thing that I see is people raising the same issue on multiple different endpoints. For example, they might raise an issue for finding SSRF on each of the tools on and I'm not entirely sure that's right. I get the feeling that things like this are done for multiple acknowledgements or on sites like HackerOne, where you get reputation or points, is to artificially boost their score.

Questionable behaviour

All of the above is pretty harmless and I'm guessing they are problems that everyone who has a bug bounty program deals with. One thing that I have started to see more and more recently though is something that I detest. Receiving an email with a title like "Critical security vulnerability" is never a nice experience for someone that runs or is responsible for a website so you open it up and get reading ASAP. The email details how they have found a critical security vulnerability in your application that needs immediate attention and asks for details of any bounty program you have and the rewards. I normally inform them of the program on HackerOne that I can invite them to but inform them that there is no financial reward due to the sites being free services. At this point our expectations of how things should proceed usually differ. Upon finding out that there is no financial reward for disclosing a vulnerability these researchers are then not prepared to send me details.


You may disagree with me on terminology here but to be on the receiving end of an email that says we've found a critical security vulnerability in your site but I'm not going to tell you unless you pay me certainly feels like extortion. On one hand, I want to be as responsible as possible and if my users are at risk then I need to know and patch this issue to protect them. On the other hand this is such irresponsible and unethical behaviour that interacting with this person seems out of the question. Their behaviour and approach calls into question their motives. They've effectively conducted a penetration test against my website, without permission, and are trying to extract money out of me.

email 1

email 2

I've received several emails like this over the last few months and I've always followed up. I explain that the services are free and there is no financial reward on offer but I'm happy to provide appropriate credit or invite them to my HackerOne program. Not a single one of them has been prepared to agree to these terms and I've also received some interesting response about how irresponsible I am for not being prepared to pay for details of a critical vulnerability. I'd be really interested to hear your thoughts on this and perhaps any similar experiences you've had, what action you took and the outcome.

If you would like an invitation to my HackerOne programs then please drop me an email and I will invite you. Perhaps there is a critical vulnerability in one of the sites that I've yet to find but I've enlisted the help of many former colleagues and friends in the security community to conduct their own testing after receiving emails like this and nothing has turned up yet. Perhaps the critical vulnerability they've found is another SSRF issue, I just don't know, but I can't and won't be forced into paying for the information in this manner.