Broken access control
Objects reachable by anyone who knows the identifier. The request is authenticated; the authorization check is missing, or it trusts a value the client controls.
soybeta.
Bryan González. I build SaaS products, and I look for broken access control in the web applications and APIs that other people build.
01
What I look for
Improper authentication
Session binding, token scope and password-reset flows that trust the wrong thing — the gap between who a request claims to be and who the backend verifies.
Information disclosure
Secret tokens and private identifiers that end up where nobody meant them to go: URLs, referrers, logs, error pages and third-party analytics.
Stored XSS
Persisted input that executes in somebody else's session. What matters is the account it reaches, not that a dialog box opened.
02
How I work
Surfaces
Web applications, HTTP and WebSocket APIs, and source code. Open-core projects publish the code their hosted product runs on — that code gets read, not guessed at.
Authorization
I test only what a program's policy puts in scope, and only where there is written permission behind it. Out of scope means untouched, even when it belongs to the same company.
Method
Manual testing against accounts I own, with a second account to prove the boundary is real. No automated scanners against production unless a program asks for them.
Reports
Reproducible steps, a working proof of concept, a negative control, and impact stated in terms of what an attacker actually gets. Nothing destructive, no data kept.
03
Responsible disclosure
Found something on a domain of mine, or want a second pair of eyes on yours? Write to me directly.
Contact: mailto:bryan@soybeta.dev Contact: https://hackerone.com/soybeta Preferred-Languages: en, es Canonical: https://soybeta.dev/.well-known/security.txt Expires: 2027-09-01T00:00:00.000Z