From Zero to Security Researcher: How I Found a Critical IDOR Vulnerability at Swiggy.

From Zero to Security Researcher: How I Found a Critical IDOR Vulnerability at Swiggy.

Legal Disclosure Notice

Publication Date: June 2026 Finding Reported: June 2020 Confidentiality Period Expiration: June 2025 (5 years)

This article is published pursuant to the expiration of the 5-year confidentiality period specified in Swiggy's Bug Bounty Program Non-Disclosure Agreement. Prior notification was provided to Swiggy Security Team before publication.

What This Article Includes:

Vulnerability class (IDOR)
General technical explanation
My testing methodology
Responsible disclosure process
Acknowledgment that the vulnerability has been fixed

What This Article Does NOT Include:

Proprietary Swiggy systems information
Current architecture or code
Real user data or personal information
Information that could exploit the fixed vulnerability

INTRO Six years ago, I discovered a vulnerability that exposed millions of invoices on Swiggy. This is how I found it, reported it responsibly, and what it taught me about security testing.

This wasn't a high-profile bug bounty. I wasn't the first to report it. But it was the vulnerability that taught me the most about systematic security research, the power of responsible disclosure, and how even "simple" features can have catastrophic security implications at scale.

THE DISCOVERY I was testing Swiggy's web application methodically, like I do for all major platforms. My approach is straightforward: understand the user flow, find the sensitive endpoints, and test for common vulnerabilities.

While navigating the order history, I noticed something interesting: the invoice download link had a parameter called token. I grabbed one of my own order numbers and tried something.

Result: I got another user's invoice. In PDF form. With their delivery address, payment information, and order details.

I wasn't authenticated as that user. I didn't have their login credentials.

What is IDOR?

IDOR stands for Insecure Direct Object Reference. It's a fancy way of saying: "The application uses object references (like order IDs, user IDs, invoice numbers) to access data, but doesn't check if the user is authorized to access that specific object."

RESPONSIBLE DISCLOSURE

How I Reported It

When I discovered this vulnerability, I immediately stopped testing. I didn't download other users' invoices beyond confirming the vulnerability. I didn't share it with anyone. Instead, I documented everything carefully.

My report included:

Clear description of the vulnerability

IDOR on the invoice endpoint
Step-by-step reproduction
No authentication checks

Impact assessment

Millions of users affected
Sensitive PII exposed (addresses, payment info)
Could be automated for mass data theft
Aligns with Swiggy's own "Critical" severity definition

Proof of concept

Screenshots of the vulnerability in action
Redacted personal information
Clear demonstration of the issue

Swiggy's Response

I sent my report to security@swiggy.in in June 2020.

Within 2 days, I received a response:

"Hi Binu,

This is already reported by another security researcher. Our team is looking into it.

Thanks and Regards, Security Engineering"

I was not the first. Another researcher had found and reported this exact vulnerability earlier. But Swiggy acknowledged my submission, and their security team continued working on a fix.

Within weeks, the vulnerability was patched. Swiggy added proper authentication checks to ensure users could only download invoices they own.

Why Responsible Disclosure Matters

I could have:

❌ Exploited the vulnerability to download real user invoices for profit
❌ Shared the exploit publicly
❌ Demanded a large bounty
❌ Gone silent and waited for someone else to report it

Instead, I:

✅ Documented the issue thoroughly
✅ Reported it through official channels
✅ Stopped testing immediately after confirming it
✅ Respected the company's process
✅ Waited for their fix without public disclosure

Result: The vulnerability got fixed. Millions of users stayed protected. And Swiggy's security team trusted me as a responsible researcher.

Even though I didn't get a bounty (it was already reported), my professional approach built credibility. That matters more in the long run.

LESSONS LEARNED

Lesson 1: IDOR is Everywhere

This wasn't a new vulnerability type. IDOR has been known for decades. But it's still one of the most common and impactful vulnerabilities in real applications.

Why? Because developers often think:

"These are just internal references"
"Nobody would guess the ID format"
"We'll add authentication later"

Then "later" never comes, and millions of records are exposed.

Check your own applications: Can users modify IDs and access other users' data? If yes, you have an IDOR vulnerability.

Lesson 2: Scale Amplifies Impact

This vulnerability would have been problematic on any platform. But on Swiggy — with millions of users, thousands of daily orders, years of invoice history — the impact was massive.

An attacker with this vulnerability could:

Access complete order history of millions of users
Build profiles: what people ordered, when, how much they spent
Map delivery patterns: where people live, where they work
Extract payment information
All in an automated script running 24/7

Scale doesn't just make vulnerabilities bigger — it transforms them from "a problem" into "a critical privacy breach."

When you're testing applications, always ask: "What if an attacker uses this at scale?"

Lesson 3: Sequential IDs Are a Red Flag

Whenever you see a sequential ID, immediately check:

Is it authenticated?
Is it rate-limited?
Can I enumerate all values?
What data can I access?

Sequential IDs aren't automatically insecure. But they're a red flag that demands careful security review.

Lesson 4: Ethical Practices Build Credibility

I could have made this about the bounty or the recognition. Instead, I made it about doing the right thing:

Report properly
Don't exploit it
Respect the company's process
Help them fix it

Six years later, that reputation mattered more than any single bug bounty would have.

Lesson 5: Being Second Doesn't Mean You Failed

I wasn't the first to report this. Another researcher beat me to it. But my detailed report, my responsible approach, and my professionalism still had value.

In security research, you won't always be first. But you can always be professional, thorough, and ethical. Those qualities matter more.

CONCLUSION

Security research is a long-term commitment. It's not about one big payday or one spectacular finding. It's about building a reputation for systematic thinking, ethical practices, and genuine interest in making systems more secure.

This IDOR vulnerability didn't make me famous. I didn't get a massive bounty. But it taught me:

How to approach security testing methodically
How to report findings professionally
How to think about impact at scale
Why responsible disclosure actually works

Six years later, I'm still finding vulnerabilities. I'm still testing systematically. And I'm still reporting them responsibly.

The journey from finding my first vulnerability to becoming a respected security researcher isn't about the quick wins. It's about the consistency, the ethics, and the commitment to making applications more secure.

If you're starting your security research journey: be systematic, be responsible, and be patient. The credibility you build will matter far more than any single finding.

Key Takeaways

✅ IDOR vulnerabilities are about authorization, not authentication ✅ Sequential IDs are a security red flag ✅ Scale amplifies the impact of vulnerabilities ✅ Responsible disclosure works — even if you're not first ✅ Professional reputation matters more than bounties ✅ Security research is a long-term commitment

About This Finding

Reported: June 2020
Vulnerability Type: IDOR (Insecure Direct Object Reference)
Severity: Critical
Status: Acknowledged by Swiggy Security Team, fixed by their team
First Reporter: Another security researcher (I was not first, but reported responsibly)
Impact: Millions of invoices potentially exposed
Lesson: Being second doesn't mean failing if you report professionally
Confidentiality Period: Expired June 2025 (5 years post-disclosure)

Acknowledgments

Thank you to Swiggy's security team for addressing this vulnerability promptly
Special appreciation to the security research community for maintaining ethical standards
Gratitude to the researcher who reported this first — responsible disclosure means everyone wins

This article is part of my ongoing security research portfolio. I practice responsible disclosure on all platforms I test. This publication follows industry best practices and the expiration of the confidentiality period specified in Swiggy's Bug Bounty Program.

#IDOR #VulnerabilityResearch #ResponsibleDisclosure #CyberSecurity #BugBounty #SecurityResearch #WebSecurity #InfoSec #Swiggy #AuthenticationBypass #SecurityTesting

Contents