We recently published a comprehensive but abbreviated guide ‘Anatomy of a Bounty Brief’ which explores each part of a bounty program brief and how organizations can write them more clearly and thoughtfully.
Once you’ve identified that you and your organization are ready to commit the necessary time and resources to running a bug bounty program, it’s time to start building out your program brief – the first step of which, is setting the program scope.
First off, it’s important to first know what you want tested. Since this varies widely by company/need, we’ll assume you already know what it is that you intend to have tested (e.g. xyz web app, mobile apps, IoT, etc).
For the sake of simplicity, we’ll say you’re the proud owner of https://myapp.com, and want your app ‘myApp’ to have a bug bounty program.
In setting the scope for your program, it’s important to underscore just how critical the scope is for the success of your program. In its simplest form, the scope tells the researchers what they can and can’t test – which is paramount to getting the results you want from your bounty program. Here are some things to keep in mind…
1. Leave nothing open to interpretation.
The easiest way to do this is to put yourself in the researchers’ shoes – take a step back and objectively evaluate the scope you’re articulating. If something can be misinterpreted or is ambiguous, you’re putting yourself at risk of being in the unenviable position of having to reward findings on targets that you didn’t anticipate being tested. Furthermore, if the scope is unclear, it will often result in misguided researchers either (a) not fully testing what you had desired; or (b) testing outside the bounds of what you originally imagined.
For instance, let’s say you list the scope as “https://myapp.com/app”. As a researcher, a couple questions come to mind:
1) Is all of “myapp.com” in scope, or is it only “/app”?
2) Similarly, what about content after “/app”?
What if there’s an admin functionality at “/app/admin”? Is this in scope? Perhaps you meant for all of “myapp.com” to be in scope, but wanted to direct the researchers to a specific functionality? Or maybe you forgot about the admin functionality, and actually didn’t want it to be tested. As you can see, the ambiguity creates a situation in which researchers will either end up under testing (e.g. testing just that path, and nothing else), or overtesting beyond what you had in mind (e.g. testing all of myapp.com).
Always objectively review your scope – a good rule of thumb is not just to write your scope so that it can be understood, but instead, write your scope so that it cannot possibly be misunderstood.
Instead of ending up in the above predicament, you could simply add a short sentence explaining what the scope is (i.e. “all of myapp.com is in scope, but the above url is where the majority of the app is located” also, “do not test any functionality on /app/admin”). By telling researchers explicitly where the scope ends and begins for the program, you can save yourself a lot of time and future troubles.
#ProTip: Underneath your targets section on the brief, it’s always useful to have something to the extent of “any property/domain/subdomain of [company] not listed in the above targets section, is out of scope.” While this may be inferred by exclusion, there’s no harm in making it doubly clear, just what is/isn’t in scope.
2. Know and understand your attack surface
By knowing and fully understanding your attack surface, you can more perfectly convey to researchers what is and isn’t in scope, ensuring that you get the results you want from the program. If the attack surface isn’t fully understood, you run the risk of either (a) researchers testing too little of the app; or (b) testing beyond what you had anticipated as the desired scope.
Example 1: Too Narrow of Scope
Let’s go back to the example of https://myapp.com. So, you’ve decide that you want ‘myApp’ tested, and tell researchers they can test the entirety of “myapp.com” and in learning from the above points, you state that no other domains or properties are in scope. However, as researchers begin to test, they quickly realize that the login for the app is at “login.myapp.com”, the account functionality is at “accounts.myapp.com”, the api is at “api.myapp.com”, and so on. Ultimately the researchers come to find that very little content is actually on “myapp.com” – and since all other domains are out of scope, researchers quickly grow discouraged, disinterested or bored with the narrow scope, and leave the program for fresher waters.
This is a classic case of misunderstanding your attack surface, and in turn, failing to articulate it to researchers. Even if you catch this kind of flaw shortly after launching your program, a large amount of damage has already been done. The start of a program is the most critical time to build a great impression amongst researchers, which is why it’s critical to take these things into account before launching. Take some time to spider your app, and fully understand all the parts that should be in scope for researchers to be able to perform testing on the entirety of the application that you wish to be included.
Example 2: Overly Permissive Scope
After the previous mistake, you decide to implement a quick fix, changing the scope to “*.myapp.com” (‘*.domain’ means that all subdomains are in scope). This solves the question of all those pesky subdomains by simply including them all by default.
However, (and this is a huge ‘however’) this ONLY works if you fully understand your attack surface. In nearly every situation with a ‘*.’ scope, researchers will invariably find an old subdomain or app (i.e. an ancient staging server, or something an intern hosted from five years ago) which will be vulnerable to some fairly big issues for which you’ll be expected to pay out for. These are often great findings, and everyone loves to test on a program with a “*.” scope, but before doing so, take the time to fully understand your attack surface, so you don’t find yourself paying for vulnerabilities on targets you hadn’t intended to be tested.
3. Prioritize targets intentionally
Not all targets are created equal. Applications with greater barriers to entry naturally receive less activity, which is why it’s important to remember that like any other force of nature, researchers will follow the path of least resistance. For example, if you have a web app and a mobile app (i.e. Android/iOS) that you want tested, keep in mind that the web app, simply due to the relative ease of access and testing, will see a substantially larger amount of engagement than the mobile app.
Thus, when creating your scope, assess your program goals and your security priorities. If, perhaps, the mobile app is your primary target, and receives the majority of your user traffic, it might be worth considering either (a) removing the web app from the scope to make sure researchers focus exclusively on the mobile app; or (b) providing additional incentives for researchers to focus on the mobile app, drawing their attention to the targets you care most about.
Also, keep in mind that this isn’t just limited to apps on different platforms, but can also apply to anything specific that you’d like researchers to focus on (i.e. vuln types, functionalities, etc).
Lastly, as a friendly reminder, keep in mind while building out your program, that you’re working WITH researchers, not against them. The effort that you put into creating a clear and thoughtful brief does not go unnoticed, and ultimately helps researchers be more effective in testing your application. And that’s the goal, right!?
