People picture this job as someone hammering a keyboard and "hacking in." The reality is much quieter. I work as a vulnerability assessor (a web app pentester) in Japan, and most of my day is slow, careful, repetitive work. Here's what it actually looks like, hour by hour, plus a few things that might be specific to how the industry runs here.
Morning: I don't touch the keyboard first
The first thing I do isn't launch a tool. It's check the scope of the engagement I'm working on that day.
Which domains and screens are in scope, and where am I not allowed to go? I read through whatever the client shared in the pre-engagement hearing (in Japan there's usually a fairly formal kickoff and a signed scope document), and I confirm the test accounts work. Getting sloppy here is how you end up touching a system that wasn't in scope, which is a real incident, not a small mistake. The whole job rests on one rule: only touch what you were given permission to touch. So this check comes before anything else.
Late morning: crawl the app to build a map
Once the scope is clear, I walk through the whole target like a normal user. Log in, move between screens, fill in forms, submit them. The entire time, Burp Suite is quietly recording every request in the background.
At this stage I'm not hunting for bugs yet. I'm building a map: what features exist, and where does this app send and receive data? I also count the requests to estimate how much testing the day will actually take.
Afternoon: change one request, watch what changes
This is the core of the work. I take the recorded requests one at a time, change a parameter, and look at how the response differs. Then again. And again.
Honestly, it's tedious. You repeat almost the same action hundreds of times against different targets, and the dramatic moment almost never comes. But when a response behaves differently than you expected, that "wait, there's something here" instinct kicks in, and it gets sharper the more reps you put in. Whether you can find that tedium interesting is, I think, the real test of fit for this job.
What actually turns up
This is the question I get most: "Do you find dramatic stuff like SQL injection all the time?"
In my experience, the textbook SQL injection you learn on day one isn't that common on modern sites. Frameworks tend to handle it. What I actually run into is quieter.
Broken access control (IDOR)
This is the one I hit most. Change an ID in the URL or request from your own to someone else's, and you can see their data.
It happens because the app checks whether you're logged in, but forgets to check whether you're allowed to see that particular record. During development, people test with their own data only, so it slips through. In a test, I usually set up two accounts and drop one account's ID into the other's request.
Misconfiguration and information leakage
A directory that's exposed when it shouldn't be. An error page that spills the server's internals or a stack trace. A dev file left behind in production. These "forgot to clean up" issues come up constantly.
It's less a vulnerability than leftover mess. I find it by deliberately triggering errors and watching whether the response leaks more than it should, or by knocking on common paths to see what answers back.
Outdated, unpatched components
A library or middleware with a known vulnerability, still running an old version. "It works, so nobody updated it." If a version number shows up in a response header or an error page, you can often guess that the version has a known issue from there.
Line these up and the pattern is clear: the single flashy bug is rarer than the holes that grow out of day-to-day operations. Permission checks that are too loose, cleanup that never happened, updates that got pushed off. That gap between the textbook and the field is the part I didn't expect when I started.
Evening: find it, prove it, put it into words
Finding something isn't the end. The job runs until you've captured how to reproduce it as evidence and written it up in a form that belongs in a report.
Explaining it in language the client understands matters as much as finding it. "This is dangerous" tells them nothing. What happened, what could leak, how to fix it. Whether you can write that is what separates assessors. And in Japan the report is often the actual deliverable the client pays for, so it carries real weight.
So: quiet, but deep
A vulnerability assessor's day is far more low-key than people imagine. Check the scope, build the map, keep testing requests, put what you find into words. That loop, over and over.
But the feeling of catching a "wait, this is off" inside all that quiet checking is hard to get from other work. That's what keeps me in it.
I'm an ex-network engineer who moved into security here in Japan. I'm starting to write about real-world pentesting and what this industry looks like from the inside. If that's interesting, follow along.
Top comments (0)