I'm Azyven, a self-taught web pentester

I am not a hacker

That word has been used for so long to mean criminal that it no longer describes anyone useful. When most people hear it they picture someone stealing data in a hoodie. That is not what I do, and it is not what the field is.

I am a security engineer who works on web applications. I look for flaws in software, I report them to the people responsible for it, and I write the fix. Every target I touch is either mine, a public training lab, a CTF, or something I have written authorisation to test. There is no grey area in that list, and I do not want one.

Finding a vulnerability and fixing it are the same job. Only doing the first half is what gives the field its bad name.

White hat means the fix ships

Plenty of people can find a bug. The part that matters, and the part most write-ups skip, is what happens next. When I find something, the work is not finished until it is closed:

1. 01Reproduce it from a clean state, so I know it is real and not an artefact of my session.
2. 02Reduce it to the smallest proof of concept that still demonstrates the impact — no exploit chain theatre.
3. 03Report it privately to whoever owns the code, with reproduction steps and evidence.
4. 04Write or propose the patch, in the terms of their codebase.
5. 05Re-test after the fix, because a patch that does not close the hole is worse than none: it buys false confidence.

Why I want to change the image of this job

Computing has an image problem, and security has the worst of it. People assume the skill is inherently destructive, that anyone who understands systems deeply must be up to something. It puts off exactly the people the field needs, and it makes companies treat security as an adversary instead of a service.

I learned all of this on my own, without a school, without a diploma, and without anyone telling me it was allowed. So I know how easy it is to end up on the wrong side by accident, and how much difference one clear rule makes: test only what you may test. Everything I have learned is meant to show what this job looks like when it is done properly — you build things, you check that they hold, and you fix them when they do not.

What I actually do, in detail

The work splits into a few concrete activities. They feed each other: building teaches me what developers get wrong, and testing teaches me what to avoid when I build.

• Web application testing — going through an application by hand, mapping what it does, and finding where its own rules stop being enforced. In practice that is mostly broken access control, injection, and authentication or session handling.
• Vulnerability research — reading source code to find the bug before anyone triggers it, rather than waiting for a scanner to guess. This is the slow part and the part I enjoy most.
• Patching and remediation — writing the correction, not just the report. Scoped queries, validated input, secure defaults, and a regression test so the same bug cannot come back.
• Full-stack development — I build the applications too: interface, API, database and deployment, in TypeScript from end to end. HunterFr and HuntCode are both mine, front to back.
• Infrastructure and hardening — Linux servers, containers, reverse proxies, TLS, backups. Isolation built on the assumption that something will eventually get through.
• Reporting — writing findings for the person who has to ship the fix: impact, reproduction, evidence, and a remediation they can apply the same day.

Self-taught, and still learning

No school taught me any of this. I learned by building something, breaking it, understanding why it broke, and rebuilding it properly. That is also why HunterFr exists: it is the platform I wish I had when I started, so that the next person does not have to piece it together from scattered blog posts.

If you want to talk about a security assessment, a development project, or you simply disagree with something on this page, Discord is the fastest way to reach me.