1 AI Subscription made me 100k$ in 2 months

The payout is the part people notice.

What interests me more is the gap behind each finding: the difference between what an application was supposed to protect and what it actually exposed.

My findings covered four categories. Each raises a different question about trust.

Who is making that request? Who should receive that information? What protects that endpoint? And why is that credential in the browser?

I'm keeping this account at the category level to avoid identifying private programs.

1. SSRF: When the Server Becomes the Way In

Concept illustration: a request crosses a trust boundary through a server.

A URL can look harmless.

Paste a link. Fetch a resource. Generate a preview.

But the important detail is which machine opens that link.

When an application makes a server-side request, it uses the server's network position. That makes control over the destination worth investigating.

SSRF was one of the categories in my findings. What makes this class interesting is the possibility of turning an ordinary application feature into access across a boundary.

A callback establishes that a request happened. The impact depends on what else the evidence establishes: the destination, the access available, and the information or functionality exposed.

For me, that distinction is central to explaining an SSRF finding clearly.

"The server contacted me" starts the conversation. Demonstrated impact makes the report.

2. PII Disclosure: The Interface Isn't the Whole Application

Concept illustration: personal information reaches an unauthorized recipient. All records shown are fictional.

A clean interface can hide a messy data boundary.

The page might display a name and an avatar. The response supplying that page may contain information the interface never shows.

That is why the response matters.

PII disclosure was another category in my findings. The central issue is whether the requester is entitled to receive the information — not whether the frontend chooses to display it.

For this class of issue, three questions make the impact understandable:

• Who made the request?
• Whose information was returned?
• What permission should have prevented that disclosure?

The amount of data matters, but so does its sensitivity and the access required to obtain it.

A report becomes much stronger when it explains those boundaries precisely.

If sensitive information has reached an unauthorized browser, hiding it in the interface is already too late.

3. API Misconfiguration: A Successful Response Can Be the Problem

Concept illustration: a missing access check is one possible API misconfiguration.

An endpoint returns a successful response.

For a developer testing functionality, that might look like good news.

For a security researcher, the next question is: successful for whom?

API misconfiguration was the third category in my findings. It is a broad category, so the label alone doesn't explain the vulnerability. The useful part is identifying the exact protection that failed.

An API might be reachable by design. A particular action or dataset can still require restrictions.

That distinction is where the analysis becomes interesting: compare the intended access boundary with the behavior the API actually permits.

The report should make that difference easy to see. Describe the expected restriction, demonstrate the observed behavior, and connect it to an impact.

An endpoint working correctly and an endpoint enforcing security correctly are separate things.

4. Credentials in JavaScript: A Secret Delivered to Every Visitor

Concept illustration: a privileged secret appears in a public JavaScript bundle. No real credentials are shown.

JavaScript runs in the browser.

That means the browser receives it — and the person using that browser can inspect it.

Credentials exposed in JavaScript were the fourth category in my findings.

The important distinction is between an identifier intended for public use and a secret that grants privileged access. Both can look impressive in a screenshot. Their security implications can be completely different.

A long string alone doesn't establish impact. Its purpose, validity, permissions, and exposure are what matter.

Any validation also needs to stay within the program's rules. The objective is sufficient evidence to demonstrate the issue, with minimal access.

A secret doesn't become private because it is buried inside a large file.

Where UnlimitedAI Fit Into the Work

UnlimitedAI was part of my research workflow.

The service brings multiple model families — including Claude, GPT, DeepSeek, Qwen, Kimi, and GLM — behind one API integration, with flat-price access rather than per-token billing. The available models depend on the plan. Current product details.