When “Private” Wasn’t Actually Private

I'm Ruhan Ahsan (0xruh4n), a cybersecurity enthusiast with interests in Application Security, Bug Bounty, and Penetration Testing.

Today, I want to share the story behind my first accepted security finding and how it led to my first 3-digit bug bounty.

How a simple observation led to my first accepted bug and first 3-digit bug bounty

There's a common assumption users make when they enable a privacy setting:

If something is marked as "Private," it should actually be private.

That expectation seems obvious. But in application security, obvious assumptions are often worth testing.

Recently, while performing security testing on a platform as part of a bug bounty program, I encountered a privacy-related issue that became both my first accepted bug and my first 3-digit bug bounty reward.

Interestingly, the finding wasn't based on advanced exploitation techniques or complex payloads.

It started with curiosity.

The Observation

During normal feature exploration, I noticed that users had the ability to control profile visibility.

At a glance, the feature appeared straightforward:

Users could choose to make their profile private.

That raised a simple question in my mind:

What actually happens after privacy is enabled?

Instead of assuming the control worked correctly, I decided to validate the behavior.

After testing the feature from different user perspectives and verifying access conditions, I discovered that profile information remained accessible even though privacy settings suggested otherwise.

At that moment, I realized this wasn't only a technical issue.

It was a trust issue.

Why This Mattered

Security findings are often evaluated based on technical complexity.

But impact does not always correlate with complexity.

Privacy controls carry an expectation.

Users make decisions based on what the interface promises.

When privacy settings do not behave as expected, the consequences can extend beyond application logic:

• Exposure of personal or professional information
• Increased opportunities for profiling or social engineering
• Reduced trust in platform security controls
• Misalignment between user expectations and actual behavior

That realization changed how I think about security testing.

What This Experience Taught Me

This finding reminded me of something important:

Security testing is not only about attacking systems.

It is also about understanding users.

The most valuable lesson from this experience was learning to ask better questions:

• Does the application behave as users expect?
• Is access control enforced consistently?
• Are privacy features truly protecting privacy?
• Does the implementation match the product promise?

Sometimes meaningful findings don't begin with sophisticated tooling.

Sometimes they begin with curiosity.

Beyond the Reward

Receiving my first accepted report and first 3-digit bounty was exciting.

But the bigger reward was understanding that impactful security work often comes from observation, patience, validation, and responsible disclosure.

This experience strengthened my interest in Application Security and Penetration Testing, and it reinforced a mindset I want to keep carrying forward:

Never assume. Always validate.

Thanks for reading.

If you're learning security, keep testing, keep asking questions, and keep building responsibly.