The researcher behind the report.
I’m Anirban Banerjee, an independent security researcher focused on application security: the places where identity, ownership, and intent are translated into code.
A question before a payload.
My work concentrates on application security: web applications, APIs, authentication and sessions, business logic, and the authorization decisions that hold them together. These are the parts of a system closest to intent, and often the parts where intent is least explicit.
I’m less interested in a payload than in the model that made the payload relevant. A request that should have been impossible is usually evidence of an assumption that was never written down. Finding it starts with reading the system carefully: who it believes is calling, what it believes they own, and what it believes has already happened.
The work is part technical and part editorial. A finding only becomes useful when it can be explained clearly to the people who have to fix it. That means understanding the business rule, isolating the smallest safe proof, and separating behavior from consequence.
“The smallest details can expose the biggest weaknesses.”
A working idea, not a slogan
How the work is done.
These principles are not unique to security research. They are what keep it useful, proportionate, and trustworthy.
- 01
Scope before signal
Authorization and disclosure boundaries are established before anything is tested. Curiosity does not override permission.
- 02
Evidence over novelty
A finding matters when it is reproducible, its impact is understood, and the smallest safe proof supports the claim.
- 03
Clarity is part of the work
A report is an argument. Reproduction steps, impact, and remediation should be legible to the people who have to act on them.
- 04
Privacy by default
Customer data, credentials, private endpoints, and confidential correspondence do not belong in a public portfolio.
Security domains.
A working focus, not a ranking. Each area reflects the kind of application-layer trust decisions I investigate.
Broken access control
01Object-level authorization, ownership and tenancy checks, privilege transitions, and the gap between route protection and object protection.
API security
02Surface mapping, schema and mass-assignment risks, inconsistent enforcement between services, and assumptions about who consumes an API.
Authentication & sessions
03Identity transitions, token lifecycle, session state, account recovery, step-up flows, and trust carried across boundaries.
Business logic
04Workflow invariants, state transitions, sequence, concurrency, and decisions that should remain server-authoritative.
Security misconfiguration
05Trust boundaries that drift: verbose errors, permissive defaults, environment separation, and unintended exposure.
Client-side security
06Where browser assumptions become server-side trust: interface gating, storage, cross-origin behavior, and client-supplied state.
Working toolkit
- Burp Suite
- Caido
- Postman
- Chrome DevTools
- ffuf
- mitmproxy
- Python
A working set, not a proficiency score. Tool choice follows the question.
Research methods
- Threat modeling
- Manual authorization testing
- Differential analysis
- Workflow analysis
- Evidence capture
- Coordinated disclosure writing
Reproducible evidence, proportionately gathered.