Bug Bounty Research
Web-application security research on Bugcrowd across multiple public programs. I focus on how applications handle identity and state — access control, authentication, OAuth/SSO, and exposed secrets — mapping how a system is actually used and probing it the way an attacker would. Findings below are described by technique and impact only; all targets are anonymized and tested within authorized program scope.
View Bugcrowd ProfileAuthorized testing only. All research is performed within the published scope and rules of each program under coordinated disclosure. No target names, live proof-of-concept exploits, or reproducible steps are published on this page — findings are described by vulnerability class, impact, and remediation.
Bugcrowd Record
Three submissions across three public bug bounty programs — one accepted as an informational finding, two triaged Not Applicable for lack of demonstrated impact. Early on the platform and building a track record of clean, in-scope reports through coordinated disclosure. The value here is in the techniques and the surface they cover, shown anonymized below.
Earned achievements
Selected Research
Reported findings across public programs, anonymized. Described by technique and impact only — no target names or reproducible detail.
Secrets Exposure in Client-Side Code
An administrative API-gateway subscription key was hardcoded in a public JavaScript bundle, exposing authenticated API access to anyone who read the shipped frontend. Technique: auditing client-side bundles for leaked keys and tokens, then reasoning about what gateway-level access that key actually unlocks.
Subdomain Takeover → OAuth Code Interception
A dangling DNS record left a subdomain claimable — and that subdomain was referenced as an OAuth redirect_uri, so claiming it could intercept authorization codes. Technique: dangling-DNS / subdomain-takeover discovery chained with OAuth redirect-flow analysis.
User-ID Disclosure via Password-Reset Flow
A forgot-password flow leaked an identity-provider user identifier and allowed username enumeration, letting an unauthenticated user confirm valid accounts and map internal IDs. Technique: authentication-flow analysis, enumeration, and identity-provider information-leak identification.
Technique Deep-Dive: CSRF Forced Logout
A walkthrough from my own lab research — not a program submission — included to show how these request-forgery issues actually work.
The idea
A state-changing session endpoint accepts a cross-origin POSTwith no anti-CSRF protection. Because the request qualifies as a CORS "simple request" (a text/plain body, so no preflight) and the session cookie is set SameSite=None, a page on any origin can submit the form with the victim's cookies attached and trigger the action — forcing a logout.
Mechanism (sanitized)
<!-- Conceptual: a state-changing endpoint that skips CSRF
validation and accepts a preflight-free "simple" request.
Reserved example domains; not a working exploit. -->
<form action="https://victim.example/session/token"
method="POST" enctype="text/plain">
<input name='{"email":"a@evil.example","x":"' value='"}' />
</form>
<script>document.forms[0].submit()</script>Remediation
- •Require an anti-CSRF token (or strict Origin/Referer checks) on all state-changing requests.
- •Reject text/plain bodies on JSON endpoints so they can no longer bypass CORS preflight.
- •Scope session cookies to SameSite=Lax or Strict rather than None.
Focus Areas
Access Control & Authorization
Whether an unauthenticated or low-privilege user can reach data or actions they shouldn't — the class behind my accepted finding.
Authentication & Sessions
Login, logout, password-reset, and session handling — where identity is established and where it leaks.
OAuth & SSO Flows
redirect_uri handling, authorization-code flows, and identity-provider integrations that can be redirected or intercepted.
Secrets in Client-Side Code
Keys, tokens, and internal endpoints leaked in shipped JavaScript bundles and the access they quietly grant.
Process
Scope & recon
Read the program rules, stay in scope, and map the reachable attack surface before touching anything.
Hypothesis & test
Target a specific trust boundary and build the minimal test that would prove a real weakness.
Prove impact
Establish reproducibility and the concrete consequence — the bar that separates an accepted finding from an informational one.
Report & retest
Submit a clear write-up with severity and remediation, then verify the fix once the team ships it.