I wanted to know why it broke

I got into security about two years ago, and not for the reason people assume. I was not trying to become a hacker. I was trying to work out why a form I had built accepted something it clearly should not have. I spent an evening on it, understood what I had done wrong, and then spent the rest of the week wondering what else I had got wrong without noticing.

That question turned out to be the whole thing. Applications are systems built by people under deadlines, on top of other systems built by other people under deadlines, and the interesting failures live in the seams between them. Once you start looking at software that way, you cannot really stop.

Over time I narrowed down to web application security. Partly because it is where I already spent my time — I write web applications — and partly because it is the layer where the logic lives. Memory corruption is elegant, but a missing authorisation check on an endpoint nobody documented is what actually ends up in the incident report.

The habit I keep coming back to is this: understand the application before looking for anything. What is it trying to do, who is meant to be able to do what, what state does it hold, where does trust change hands. Vulnerabilities tend to fall out of that understanding almost on their own. Starting with a scanner and working backwards has never once worked as well for me.

I also build my own projects, and that has probably taught me more about security than any single course. Writing a CTF platform means running code designed to be attacked. Writing an encrypted messenger means treating your own server as the adversary. Writing a lone worker safety app means accepting that if your system is down, somebody might not get help. Having to make those trade-offs yourself changes how you read other people's code — you recognise the shortcut, because you have been tempted by the same one.

The rest is repetition. CTFs, mostly web. My own lab, where I can break things without consequences. Two internships that showed me how the work is actually organised — which turned out to be far more about method and communication than about tooling. And a steady pile of things I have not understood yet, which is the part I like most.

I am not going to claim expertise I do not have. I am two years in, I am still finding out how much I do not know, and that is roughly where I expect to be. What I can say is that I show up every day, I build things that are real, and I write down what I learn so that it sticks.