1. Not doing your homework beforehand

Before you even start you should be able to answer those three simple questions:

1. What does the application do?
2. What is the scope of your test?
3. What are the deliverables you need to provide?

In addition to all of the above, we can expand even further to end up having three categories to work on:

1. Application’s mission and the business use-case (what it does? who are the users? what they do within the application?)
   - Create a test account and get to know the application
   - Read documentation if provided
   - Identify the core components relaying on the authentication, authorization or processing sensitive data (PII)
2. Area or slice of the application we are going to test (specific API endpoints? admin panel? the entire application?)
   - Create a list of assets (URLs, API endpoints, (sub)domains)
   - Identify assets that are not publicly listed
3. What are you expected to provide as the result (is it a report? only a list of risks? engineering guidance?)
   - Ensure that you read the policy and terms of service for both the bugbounty platform and program itself
   - If it’s a pentest then you need a solid template for your report (examples)
   - Verify your list of assets with assets that are in the scope as stated by the specific program. Do not waste your time on assets that are out of scope.

If you can address all of the points above then you’ve a solid plan and you are in a pretty good spot to start testing.

2. Lack of respect

You should know the limits. Whether it’s the bug bounty program or security assessment for a client you should always have an understanding on what you’re allowed to do and what are the restrictions. If there is a risk of exposing the personally identifiable information (PII) you should be really cautious since it might cause legal issues and you don’t want to get sued.

If you found a vulnerability and you believe that further exploitation would expose users data — STOP and contact your client/program directly to check if you can move forward.

It’s easy to get over-excited when you find a serious vulnerability in the system and you start acting irrationally trying different exploits or triggering shell commands. Do not be that guy from the “Instagram’s Million Dollar Bug” — where Alex Stamos (back then CSO at Facebook) called researcher’s employer directly to report his shady activities.

You should always obey the rules. It’s better to be safe than sorry and always ask questions if you are unsure.

3. Do not burn all of your findings at once

It’s tempting to share a vulnerability right after you found a one. Think twice before you will do that as it may ruin your potential kill chain and reduce the final payout. You might be able to chain multiple vulnerabilities together.

If you locate an open redirect you might want to keep it and explore all of the system avenues before sending a report — you might find more. There is a great writeup from NahamSec where he described a similar scenario in the article “Chaining multiple vulnerabilities to get admin access”.

There is at least a one exception where I believe stacking up vulnerabilities is not a good idea. Whenever you find a critical bug that would be devastating for a client it might be better to share it right away and skip the process of building more advanced POC.

4. Using default configuration for your tools

Whenever you are using a new tool you should allocate some time to learn what features this tool does offer. You might be surprised how helpful some of them might be.

Just a few examples:

• sqlmap — by default the HTTP user-agent header is set to sqlmap/1.0-dev-xxxxxxx (http://sqlmap.org) . It’s easily and often blocked by firewalls. Set the--random-agent option instead to use a legitimate browser string. [ref]
• nmap — it’s not only a network scanner but it’s capable of running scripts (NSE) that could, e.g. check if target is affected by known vulnerabilities (nmap cve scan)
• wfuzz — probably the most common fuzzer for the web, but not everyone knows that it comes with another tool called wfpayload. This tool is capable of analysing saved sessions or even run plugins on findings to do offline analysis.

Do not throw random tools into the play praying that you will hit a jackpot. Always read the documentation as it might save you a lot of time in the future.

5. Do not refuse to learn from the experience of others

The 2020 research from BugCrowd says that:

[…] 89% of security researchers use the details released to help find more critical issues in the same or similar programs […]

You can learn a lot from previously disclosed reports including but not limited to new techniques, tools or even methodologies. If there are reports available from the program that you actively work on then it’s even better — learn, hack, repeat.