Why I Stopped Fighting Burp and Built My Own Listener

I was doing a pentest on a UAT web app for a financial company — student loan servicing. Internal only, IP filtered, VPN access. I had two accounts to test with: sales, and super admin.

Day one, Burp didn't work. Not slow. Not buggy. Just didn't work.

Three Days of Nothing

I thought it was me. New laptop, new certs, something set up wrong on my side. So I checked everything:

• Reinstalled the CA cert. Twice.
• Set Burp to HTTP/1.1 only, since the app looked like it didn't support anything newer.
• Asked IT to uncheck some settings blocking the proxy. They said they unchecked everything. Still nothing.

I also had a corporate laptop with SeroPOS installed — some kind of security software IT puts on company machines. I asked them to uncheck it in there too, thinking it was intercepting my traffic before Burp could see it.

Still didn't work. Not in Burp. Not in Caido. Not even in Firefox or IE without a proxy.

Then a pattern showed up. Four or five requests would go through fine. Then it would stop. Timeout. Then, after 15-30 minutes, sometimes an hour, it would start working again for a few requests. Then stop again.

The strange part: if I sent the exact same request twice, it worked. If I changed anything — added a quote, a script tag, anything unusual — it just went silent. No response, nothing. I thought it might be caching, but there was no cache header anywhere. Nothing explained it.

Three days gone. Barely any usable traffic captured. That's a real hit to your confidence, especially when you're new and don't have five other explanations to fall back on.

What Actually Helped

While I was stuck fighting the proxy, I started reading the app's JavaScript instead — no proxy needed for that, it's just sitting in the browser. That's how I learned the loan application flow, the roles, how the frontend talked to the backend. I understood the app. I just still couldn't test it properly.

That's when it clicked: the problem wasn't my setup. The problem was that a proxy sits in the middle of every request and decides whether it survives. If the connection between me and the app was already unstable, adding another tool in the middle — one that decrypts and resends everything — was making it worse, not better.

So I stopped trying to sit in the middle. I decided to just watch instead.

First Try: A Browser Extension

The browser already sees every request that goes out — you can see it in the Network tab, no proxy needed. So I built a small extension to grab that traffic and save it to localStorage.

It worked right away. Then it got slow. Then it got really slow. localStorage isn't built to hold thousands of requests — it's not a database — and the extension started dragging the whole browser down. Fine for testing the idea. Not usable for a real app with 200+ endpoints across two roles.

Simple lesson: the browser is a good place to watch traffic, a bad place to store it.

Second Try: Capture Here, Store There

So I split the job. The extension does one thing only: see a request, send it out immediately, forget about it. No storing anything in the tab.

I built a small listener — a program on my own machine — with one job: listen on a port, accept requests at /capture, save them. Since the extension isn't holding onto anything, it doesn't slow down no matter how long I run it.

First problem I hit: CORS. When the extension tried to send data to my listener, which is a different address than the page it's watching, the browser sends a check first (called a preflight request) asking if that's allowed. My listener didn't know how to answer that check, so every single request failed before it even started. I hadn't built that in. Once I added the right response to that check, it started working immediately.

From there it was simple:

• Every request and response gets saved as one line of JSON per line, so I can add to it forever without breaking the file if something crashes.
• I can filter it to only capture one domain, or leave it blank and catch everything from every tab.
• A simple screen to scroll through what came in, like Burp's history.
• Export to whatever format I need next — raw requests, Postman, HAR, or a list of URLs for other tools.

None of this is a new idea. It's the same idea behind tools like mitmproxy, or the small single-purpose tools some researchers build and chain together. The only real difference is I stopped trying to be a proxy. Watch, don't sit in the middle. Save it simply. Export it in whatever shape I need.

What It Found

Once traffic was flowing properly — no more timeouts, since nothing was sitting in the path anymore — I did the boring but useful part. I crawled the app as the sales account and exported every endpoint it touched. Then I crawled it again as super admin and exported that list too. Then I compared the two.

Anything that showed up in the admin list but not the sales list became something to check: what happens if I send that exact request, but with the sales account's token instead?

Out of a couple hundred endpoints, a good number of them just worked. No check on the backend for who you actually are — just an assumption that if you can't see the button, you can't hit the request. Some of it was serious for a financial app: things like changing another user's password, changing their email, turning off their 2FA, changing their phone number, or creating new accounts and bank records that a sales account should never be able to touch.

I won't go into the exact requests here — that's client data, not something for a blog post. But the pattern is worth remembering, because it shows up constantly: the frontend checked the role. The backend didn't. That gap is where most of the real damage happens in these kinds of tests, and you don't find it by clicking around — you find it by comparing what each role can actually reach.

The Short Version

If I had to tell someone on day one what I now know:

1. A proxy is a tool, not a requirement. If the network fights interception, stop forcing it. Watch the traffic another way.
2. The browser already sees everything. You often don't need to sit in the request path — you need a better place to watch from.
3. Keep watching and storing separate. If one tool does both, one job starts slowing down the other.
4. You don't need to rebuild Burp. You need the small part of Burp your situation actually needs.
5. Real bugs come from comparing, not clicking. Two role-based crawls and a comparison will show you more broken access control in an afternoon than a week of manual testing.

The tool is close to ready — capture, storage, export.
More on that soon.

But the part worth remembering isn't the code. The three worst days of this test — the ones that felt like wasted time — were the ones that forced this idea. I just didn't know it yet.