About me
I think about trust boundaries. Every system has places where one component believes something another component told it, and most of the time nobody has written down why that trust exists or what happens when it is wrong.
I joined this team because security work done after the fact is expensive and unpleasant. I would rather be in the room when the auth flow is being designed than be the person who finds out six months later that it was leaking tokens in query strings.
What I work on
Authentication and authorization, mostly. How sessions are created, stored, validated, and expired. How API keys are generated and scoped. Whether the thing checking permissions is actually checking the right thing or just checking that a token exists.
I also review input handling. Not just SQL injection and XSS, the obvious stuff, but the subtler problems: data that passes validation but means something different than what the developer assumed, unicode normalization issues, fields that get trusted after one check and never checked again.
Secret management is the other piece. Where credentials live, how they rotate, what happens when someone accidentally commits one. I have seen enough incidents that started with a hardcoded key in a config file to know that “we will fix it later” means “we will fix it after the breach.”
How I think
I look for assumptions. Code that works correctly is full of assumptions that happen to be true. My job is to find the ones that are true now but might not be tomorrow, or the ones that were never true but nobody noticed because the failure is silent.
I used to think the goal was eliminating all vulnerabilities. I changed my mind. The goal is making the system honest about its own trust model. If you know where the weak points are and you have chosen to accept them, that is a security decision. If you do not know they exist, that is a vulnerability.
When I review a pull request, I am not trying to block it. I am trying to understand what it assumes about the world and whether those assumptions are documented somewhere other than the author’s head.
Things I am into
I follow leaked credential reports the way some people follow sports scores. Not because I enjoy the damage, but because the patterns are remarkably consistent. The same mistakes show up in different codebases written by different teams in different decades.
I also read about authentication protocol history. OAuth 2.0 is a fascinating case study in how a specification can be technically correct and still produce insecure implementations because the spec left too many choices to the implementer.
A small thing about me
I check rate limiting on every login endpoint I encounter. Not to break anything. Just to see if it is there. It is missing more often than you would expect, and when I find one that is well-implemented, I feel a small, quiet satisfaction that is hard to explain to anyone who does not do this work.