Security tester

Security testing across the product: the API, the dashboard, the infrastructure, and the internal tools nobody outside the company is supposed to see. Authentication, authorization, rate limits, tenant isolation, data exposure, input handling, secrets, logging. The unglamorous parts, mostly, plus the edge cases regular QA would never think to try.

Testing the product itself. Our public APIs, dashboards, admin tooling, customer workflows. You're looking for broken access control, IDORs, auth bypasses, injection, unsafe redirects, weak session handling, leaked data. The practical stuff that costs customers trust.

Abuse and misuse. A lookup API can be perfectly secure and still trivial to abuse. Part of this job is thinking like a fraudster, or a careless customer, or a developer with too much time and no bad intent n finding where our own product behavior creates the risk, and helping us close it without making the API miserable to use.

Test plans that survive contact with reality. You'll build structured plans for new features and releases, then turn the parts that matter into repeatable checks. Some manual, some automated. All of it clear enough that an engineer reading the output knows what broke and why.

Bug reports we can act on. Impact, repro steps, affected surfaces, severity, a fix worth trying. No theater. If something matters, you should be able to say why without inflating it.

Regression coverage. Once we fix something, it should stay fixed. Tests, checklists, scanners, fixtures, review patterns, whatever it takes to keep old mistakes from wandering back in.

Security as a habit, not a department. Clear feedback, practical threat modeling, checklists people actually use, calm thinking when something goes wrong.

Month one is learning. The product, the APIs, the auth model, the data flows, the internal tools, and every security assumption we're currently making without having written down. You'll run a first full testing pass and give us a risk map of where the real gaps are.

By 60 days you're in the release flow. Core areas tested, fixes reported and retested, severity standards defined, repeatable plans in place for auth, access control, sensitive data, and API abuse.

By 90 days the security testing roadmap is yours.

New work should ship with fewer surprises. Old issues shouldn't come back. And we should all have a much better sense of where risk actually lives, rather than where we assume it does.

Someone hands-on with real judgment. You've tested live web applications or APIs, you know the common vulnerability classes, and you can prove impact without breaking things you shouldn't.

Comfortable with HTTP, APIs, auth flows, access control, Burp or similar, basic scripting, logs, cloud fundamentals, and enough code reading to form a theory about what's going wrong.

The tools matter less than the thinking. We want someone curious, precise, hard to rattle, and good at telling real risk apart from noise. You write clearly. You say things directly. You don't need every test case handed to you.

Nobody has all of it. Sharp reasoning and good instincts count for more.

You want to run scanners and forward the output. You like inflating severity. You need a large security team around you to know what to do next. You treat engineers as the opposition, or you'd rather sound dangerous than make anything safer.

This one asks for patience, taste, and ownership.