What is a security vulnerability?

Our industry has dozens of definitions for what is a security vulnerability, and instead of providing our own, what we would rather ask you, is that when you claim something to be a vulnerability, you explain in your own words, why you think the behavior is dangerous, and explain how it affects the application in practice. In fact, when you report a vulnerability to us, we always ask you to provide a good attack scenario, and when discussing whether something is or isn't a vulnerability, we will focus mostly on whether the attack scenario you provide is something we care about or not (rather than on the meaning of the word).

One of the things we see often, is that people discover some behavior that is dangerous in some cases (and has a valid attack scenario), and try to generalize it. An example of this is being able to upload files to a web server, which for some cases might indeed be a vulnerability, but it doesn't mean that every website that allows you to upload files is vulnerable (such as Google Drive!). Being able to notice a hasty generalization is also crucial when describing the impact a vulnerability might have beyond the few cases when it is dangerous.

This also applies for more famous vulnerabilities like SQL Injection, XSS and even RCE as root! For example: Being able to inject arbitrary HTML and JavaScript code is not always a vulnerability, since it might be on purpose that an application allows other sites to execute scripts on their page, and that is done in a way that is not dangerous to anyone. In the same way, code execution as root is not always a vulnerability, it might also be a service provided to users. We list more examples of these cases in the Non-qualifying findings section of this site (such as logout csrf, lack of x-frame-options, lack of hsts, open redirects), which are the most common reports we receive, usually found automatically, but for which unfortunately, automated tools can't automatically describe attack scenarios (and unfortunately, we get sent copy-pasted descriptions of the vulnerabilities instead of attack scenarios).

Another of the most common problems we see when discussing with bug hunters the merits of a report are the pre-requisites of an attack, and how they differentiate from the consequences (for example, if you get code execution in a user's machine, you can steal their credentials). This is more eloquently discussed in this article by Michal Zalewski, but the gist is that often the consequences of such attacks are irrelevant, expected, acceptable, or unrealistic.

As such, if we end up in an argument about whether something is a vulnerability or not, we'll usually point you to this page, and ask you to please help us understand your attack scenario instead :-)