A lot of people in the community have been asking how I approach a web application and how I do main app hacking during bug hunting. So today, I want to share what I know and what I personally do whenever I am hacking on the main app of a target.

I am not writing this so you can copy my exact approach step by step. I do not think that is the best way to learn. The best way to get good is to build your own style over time. What works for me may not fully work for you, and that is fine. The important thing is to understand the mindset behind it and then shape your own process.

There is a quote I came up with that explains a big part of how I think **if you go deep and hit a dead end, go wide**.

What I mean by that is, if you spend time going deep into the main application and you do not find anything useful, then start going wide. Look for other assets, subdomains, related applications, or other places you can poke at. But this does not change the main idea of going deep. The moment you land on another interesting or critical asset, you still go deep on that one, too. So, in a way, the whole thing becomes a loop. You go deep, then wide, then deep again.

When I first get on the main app, like `www.example.com`, one thing usually comes to mind **click every button**. I learned that idea from Katie. But after some time, I realized I needed to build my own approach because clicking every button is not effective for me.

Why do I say that ?

Because when I click around too much and then go back to Burp or Caido history, I start seeing a lot of HTTP requests, and I cannot clearly tell what request came from what action. At that point, I get confused. I cannot properly understand the flow, and once that happens, my testing becomes messy.

That is why I had to build a simpler approach for myself.

The first thing I do when I land on the target in my browser is look at the **Network** tab, especially the JavaScript files the application is loading. I want to know what JS the app depends on. I save those JS URLs, and then I use Claude Sonnet 4.6, or any model I want, to look for possible security issues in the JavaScript code.

Now, this part is important. AI will not do the exploitation for me. It will only point out potential issues, interesting gadgets, secrets, endpoints, leaks, and other things that may or may not matter. Some of them will be impactful, and some will not. But even when it is not a full vulnerability by itself, it can still give me something useful to explore manually. That is all I need from the JS stage.

So from the JavaScript, I am usually looking for things like hidden endpoints, interesting parameters, exposed secrets, internal paths, unsafe sinks, gadgets, and anything else that could become useful later. After gathering all that information, I save everything inside VS Code. That way, I can always go back to it whenever I notice something interesting while testing the application deeper.

Then I return to the main app itself.

Like I said earlier, I do not like the "click every button" method. For me, it is not efficient. Instead, when I notice a feature or functionality in the app, that is where I focus. I try to understand that feature first. I want to know why it exists, what it is supposed to do, how users interact with it, and what kind of data or actions are tied to it.

Before I even try to break it, I ask myself a simple question

**If I break this functionality, what is the impact ?**

If the answer is "nothing serious" or "no real impact," I usually skip it and move on to something better. I would rather spend my time on a feature that can actually lead to a meaningful bug than waste energy forcing something with no value.

When I do start testing a functionality, I still do not randomly click everything inside it, I turn on Burp intercept first so I can capture the exact request tied to that action. That way, I know what the request is doing and where it came from. I can say, "Yes, this request came from clicking this specific button."

Once I capture the request, I start playing with it in Burp Repeater. I test inputs, parameters, IDs, states, roles, flows, and whatever else looks interesting. I usually do not enter the test with one fixed vulnerability type in mind. Most of the time, once I look at a request closely, I already start getting ideas of what kind of bug could exist there.

That is basically my approach.

Another thing I think is very important is having a **focus** or **goal** while testing.

For example, imagine you find a functionality that says, "You can only see another user's email after they accept the invitation." That statement alone can give you a full direction for testing.

Your focus becomes the invitation flow.

Your goal becomes this **find a way to access the user's email before they accept the invitation, or while the invitation is still pending**.

That kind of thinking has helped me a lot. Instead of testing blindly, I test with a purpose. I know what I am trying to achieve, and that makes my approach more direct and more effective.

So overall, that is how I approach main app hacking. It is not some magic method. It is actually very simple. I start from the main app, look at the JavaScript, collect useful information, save it, focus on important functionalities, understand the flow, capture requests carefully, and test with a clear goal in mind.

I will stop here for now because I do not want to share everything at once, and honestly, I am tired of typing.

By the way, I purchased the ZWINK IDOR course, and I will only give access to 5 people at a low cost. If you are interested, you can send me a private message on X/Twitter ( 4osp3l ).