About
Who I am, what I build, and why this particular class of bug.
Two careers spent on things that fail quietly.
I was a Marine, and then a Firefighter/EMT. Both jobs teach you the same uncomfortable lesson: the thing that hurts people is rarely the thing making noise. It's the detail nobody checked, the assumption everyone shared, the step that got skipped because it had never mattered before. You learn to look at a situation and ask what everyone is taking for granted—because that is almost always where it went wrong.
I do software now. I write code for a living, and I spend my own hours trying to break the kind of code I write. It turns out that habit of hunting the quiet failure transfers almost perfectly. Bugs that announce themselves tend to get caught: the crash, the stack trace, the scanner alert. The ones that survive to production are usually the ones that look fine.
Which is how I ended up fixated on broken access control.
Why authorization, specifically
An authorization flaw does not announce itself. The endpoint returns 200, the JSON is well-formed, response times are normal, and the existing tests may still pass. The only thing wrong is which caller received the data. Traditional scanners cannot reliably infer access rules that have never been expressed in a machine-readable form.
That gap helps explain why broken access control remains a common serious finding—and why human testing is so often required. It is repetitive work that does not automate easily, which makes it exactly the kind of problem worth building tools for.
So I did. VardrGate makes you state your access rules explicitly and then tests them on every commit. VardrMap exists because I got tired of not being able to answer "what have I actually looked at?" VardrRunner keeps scan execution and credentials on the operator's own machine. Each one started as something I needed and could not find.
Being an engineer is the point
I approach security as a working software engineer. I ship code, review pull requests, and live with the consequences of my own architectural decisions. Findings account for existing architecture, engineering constraints, and practical remediation—because I know what it feels like to receive a report saying "implement centralized authorization" two weeks before a release.
Scope is agreed in writing
Security testing requires written authorization and a defined scope. VardrForge is being designed to compile target allowlists into generated tools, making scope enforcement part of the code rather than an operator convention.
Evidence over volume
Every reported finding includes reproducible evidence or clearly labeled uncertainty. Severity reflects demonstrated impact, and the report length reflects what was actually found. A short report where every item is real is more useful than a long one padded with scanner output.
Honest about the limits
I work full time as a software engineer, so anything I take on runs alongside that. Timelines reflect that reality, and emergency incident response is outside what I can offer. An active breach needs a team with 24-hour coverage.
What I'm working toward
The tools are the long game. Every assessment I've done has left me with the same thought—that most of what I just did by hand should have been catchable automatically, if only someone had written the rules down. I want to close that gap: make authorization testing something a team runs on every commit rather than something they buy once a year and hope covers enough.
Alongside that, the checklists on this site are the short version of what I've learned, free and copy-pasteable into your own tickets and code reviews. If they save one team from shipping an IDOR, they've done their job.
Let's talk
Questions about the tools, an authorization design you want a second opinion on, or an idea you want to argue about—I'm interested in all three. If I'm not the right person to ask, I'll tell you that plainly and point you somewhere better.