This vulnerability type rightfully took the first place. As a bug bounty hunter I often encounter this issue type. Notable CWEs included are CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, and CWE-352: Cross-Site Request Forgery.
This vulnerability type involves a lot of logic and in it's most basic form it might not as you can see in the screenshot above but then again that situation almost never happens in real life so we have to be a bit more crafty. This basic understanding of Broken Access Control (BAC) is needed though get to the more advanced vulnerabilities though so that's why i included it. In it's most basic form you are talking having access to functionality that we should not have.
In the first picture i represented vertical BAC since i am execute functionality that can not be executed by any user of my access level. I'd need a user of a higher privilege level than mine to be able to execute this functionality under normal operations.
When we talk about horizontal BAC defects we are talking about functionality that we would normally be able to execute but simply not on that specific object. Depicted below is a horizontal BAC defect but many of you may recognize this as an IDOR (Insecure direct object reference), they are the same thing.
You might find it surprising that we have to give all this extra information for a topic that seems so simple at first sight but even as pentesters it will take a whole lot of concentration to test the correct things.
Let's first imagine a hypothetical scenario where you have 10 different levels of users with 10 different functionalities that each progressively get more access to more functionality. If we want to test all functions we have to test 10 functions with 9 different functionality priviledge levels (Since we will not have to test the admin account). This is one the simplest scenario's possible where there is no overlap between different priviledge levels.
In most production environments you will find a situation similar to what we have in the drawing below.
The reason most BAC defects happen in these functionalities is because the base functionality is built and only after some time do they start working on the expansions like importing or exporting objects.
When we want to test for these types of vulnerabilities we can use several execution strategies but like with anything our attacks success will depend on our preparation to a big extend. We will have to take the time to map our target very carefully and even create a permissions matrix if our target has not done this for us. All of this is not as hard as it seems but you do have to be very diligent and know your target well.
These types of vulnerabilities are all about testing every single piece of functionality with every single privilege level that you can find. For me this starts with taking good notes and ends with taking good notes.
I usually take notes for this vulnerability type in excel since it's easier to create tables there but any note taking tool can be sufficient. On my X-axis i note down all the privilege levels (Columns) and on the Y-axis i will start noting down what functionality exists. I will then indicate if a user of that specified privilege level should be able to perform Create Read Update or Delete actions (CRUD actions)