I Wasn’t Trying to Hack Them, But I Did: A Beginner’s Story of Finding Major Security Flaws

As a cybersecurity beginner, I was just exploring a web application to learn. I never expected my curiosity would lead me to uncover critical vulnerabilities like Server-Side Request Forgery (SSRF) and Broken Access Control. This is my story of what I found.

Quick Disclaimer
Before I get into the technical details, let’s get something straight. I’m not a professional pentester — at least, not yet. I’m just someone with a massive passion for cybersecurity, trying to get my hands dirty and learn how things work in the real world.

The findings I’m about to share were discovered by pure chance while I was exploring a web application. This was not an official, authorized penetration test. Most importantly, no malicious activity was performed. I didn’t access, modify, or delete any data I wasn’t supposed to. My only goal was to learn. As soon as I realized the severity of the issues, I compiled a report and sent it to the website’s owner to help them fix things.

This is the core of being an ethical hacker: you find things to help, not to harm. Now, let’s get to the fun part.

First Domino
It all started with a simple API endpoint: /api/videoGens. In web apps, an endpoint like this is usually responsible for fetching things a user has created—in this case, videos. When you're looking at network traffic, you often see requests with parameters like page=1 and limit=10. These just help the app show you a small chunk of data at a time instead of everything at once.

My curiosity kicked in. I thought to myself, “What happens if I tweak these numbers? What if I ask for a limit of 100 instead of 10?"

Honestly, I expected to see an error or just my own test videos. But what I got back was… everything.

0x62616B61
I Wasn’t Trying to Hack Them, But I Did: A Beginner’s Story of Finding Major Security Flaws
0x62616B61
0x62616B61

5 min read
·
Sep 13, 2025

Listen

Share

More

As a cybersecurity beginner, I was just exploring a web application to learn. I never expected my curiosity would lead me to uncover critical vulnerabilities like Server-Side Request Forgery (SSRF) and Broken Access Control. This is my story of what I found.

Quick Disclaimer
Before I get into the technical details, let’s get something straight. I’m not a professional pentester — at least, not yet. I’m just someone with a massive passion for cybersecurity, trying to get my hands dirty and learn how things work in the real world.

The findings I’m about to share were discovered by pure chance while I was exploring a web application. This was not an official, authorized penetration test. Most importantly, no malicious activity was performed. I didn’t access, modify, or delete any data I wasn’t supposed to. My only goal was to learn. As soon as I realized the severity of the issues, I compiled a report and sent it to the website’s owner to help them fix things.

This is the core of being an ethical hacker: you find things to help, not to harm. Now, let’s get to the fun part.

First Domino
It all started with a simple API endpoint: /api/videoGens. In web apps, an endpoint like this is usually responsible for fetching things a user has created—in this case, videos. When you're looking at network traffic, you often see requests with parameters like page=1 and limit=10. These just help the app show you a small chunk of data at a time instead of everything at once.

My curiosity kicked in. I thought to myself, “What happens if I tweak these numbers? What if I ask for a limit of 100 instead of 10?"

Honestly, I expected to see an error or just my own test videos. But what I got back was… everything.

Press enter or click to view image in full size

My screen filled with data belonging to other users. I could see userIDs that weren't mine, along with links to the videos they had generated. My heart skipped a beat. This is a classic case of Broken Access Control.

This was a serious flaw. It meant anyone with an account could potentially snoop on content created by other users just by changing a few numbers in an API call. It was a sobering reminder of how a seemingly small oversight can have big privacy implications.

Down the Rabbit Hole
Finding that first bug made me look at the application with new eyes. I started wondering what else might be hiding under the surface. I noticed another interesting feature — a tool that could render text over a video. The API call for this was to /api/video/renderTextOverFace.

The request it sent looked something like this:


{
"text": "Preview Text",
"videoUrl": "https://some-video-url.com/video.mp4",
"fontSize": 0.059
}


Open in app
Sidebar menu

0x62616B61
I Wasn’t Trying to Hack Them, But I Did: A Beginner’s Story of Finding Major Security Flaws
0x62616B61
0x62616B61

5 min read
·
Sep 13, 2025

Listen

Share

More

As a cybersecurity beginner, I was just exploring a web application to learn. I never expected my curiosity would lead me to uncover critical vulnerabilities like Server-Side Request Forgery (SSRF) and Broken Access Control. This is my story of what I found.

Quick Disclaimer
Before I get into the technical details, let’s get something straight. I’m not a professional pentester — at least, not yet. I’m just someone with a massive passion for cybersecurity, trying to get my hands dirty and learn how things work in the real world.

The findings I’m about to share were discovered by pure chance while I was exploring a web application. This was not an official, authorized penetration test. Most importantly, no malicious activity was performed. I didn’t access, modify, or delete any data I wasn’t supposed to. My only goal was to learn. As soon as I realized the severity of the issues, I compiled a report and sent it to the website’s owner to help them fix things.

This is the core of being an ethical hacker: you find things to help, not to harm. Now, let’s get to the fun part.

First Domino
It all started with a simple API endpoint: /api/videoGens. In web apps, an endpoint like this is usually responsible for fetching things a user has created—in this case, videos. When you're looking at network traffic, you often see requests with parameters like page=1 and limit=10. These just help the app show you a small chunk of data at a time instead of everything at once.

My curiosity kicked in. I thought to myself, “What happens if I tweak these numbers? What if I ask for a limit of 100 instead of 10?"

Honestly, I expected to see an error or just my own test videos. But what I got back was… everything.

Press enter or click to view image in full size

My screen filled with data belonging to other users. I could see userIDs that weren't mine, along with links to the videos they had generated. My heart skipped a beat. This is a classic case of Broken Access Control.

This was a serious flaw. It meant anyone with an account could potentially snoop on content created by other users just by changing a few numbers in an API call. It was a sobering reminder of how a seemingly small oversight can have big privacy implications.

Down the Rabbit Hole
Finding that first bug made me look at the application with new eyes. I started wondering what else might be hiding under the surface. I noticed another interesting feature — a tool that could render text over a video. The API call for this was to /api/video/renderTextOverFace.

The request it sent looked something like this:

{
"text": "Preview Text",
"videoUrl": "https://some-video-url.com/video.mp4",
"fontSize": 0.059
}
The videoUrl parameter immediately caught my eye. To put text on a video, the server has to download that video first. This is where a little red flag went up in my head. What if, instead of a real video URL, I gave it something else? Something on an internal network, or even better, a URL that I control?

This is the setup for a very dangerous vulnerability called Server-Side Request Forgery (SSRF).

In simple terms, SSRF is like tricking a company’s internal mail service. You give a mail clerk a letter and an address. They’re supposed to deliver it outside the company. But instead, you give them the address of the CEO’s office inside the building. The mail clerk, just following instructions, goes there and delivers your message. You, the attacker, have just made the server do something it was never intended to do — access its own private network.

To test this theory, I did the following:

I set up a listener. I used a free online tool that creates a unique URL and shows me any web requests that come to it. This was my “trap.”
I crafted a special request. I targeted the /api/video/renderTextOverFace endpoint, but for the videoUrl, I put in the unique URL of my listener.
I sent the request and held my breath.
A few seconds later… BINGO! A new request appeared on my listener.

between a security researcher and a criminal is thin, and it’s defined by intent and action. Always have permission or, if you find something accidentally, report it responsibly and never, ever cause damage.
This journey from a curious beginner to someone who found and reported real-world vulnerabilities was thrilling. It solidified my passion for cybersecurity and reminded me that there’s always something new to learn, and that sometimes, the best way to learn is to just dive in.

Stay Curious, Stay Secure…