CSRF Validation Bypass: How I Tested Swiggy’s API Security

The Discovery

In June 2026, I discovered a CSRF validation bypass vulnerability on Swiggy's address API endpoint where the server doesn't validate CSRF tokens.

This finding demonstrates an important lesson in API security: even "simple" endpoints deserve thorough security testing.

The Vulnerability

The Issue: The server accepts requests with empty or missing CSRF tokens and still returns sensitive user address data.

What This Means: A CSRF (Cross-Site Request Forgery) vulnerability requires proper token validation. Without it, a malicious website could potentially perform unauthorized actions on behalf of a logged-in user.

How I Found It

My testing methodology was straightforward and systematic:

Identified the endpoint — Tested the Swiggy address API while navigating the website
Noticed the gap — CSRF token validation wasn't being enforced
Confirmed the vulnerability — Sent requests with null/empty CSRF values
Verified the impact — Server still returned sensitive address data

This systematic approach revealed what might have been overlooked in a less thorough review.

Why It Matters

CSRF vulnerabilities are often dismissed because they seem to require specific conditions. But the reality is different:

At Scale:

With millions of users, even "conditional" vulnerabilities become significant
Sensitive data like addresses can reveal user location, home/work patterns
Could potentially affect user privacy if exploited

In Context:

This endpoint handles personally identifiable information (PII)
User addresses are highly sensitive data
Proper validation is non-negotiable for such endpoints

My Responsible Disclosure Process

What I Did:

✓ Documented thoroughly — Detailed findings and reproduction steps
✓ Reported professionally — Sent to security@swiggy.in with clear communication
✓ Respected the process — Waited for Swiggy's official review
✓ Didn't exploit further — Confirmed the vulnerability and stopped testing

Swiggy's Response:

Hi Binu B,

Thank you for your patience and for your continued efforts in responsibly disclosing security vulnerabilities to Swiggy.

We have completed our review of your report regarding the CSRF validation bypass on the /dapi/address/all endpoint. At this time, we are marking this report as Informational.

Best regards, Swiggy Security

Key Lessons Learned

Lesson 1: CSRF Validation Should Never Be Optional

Proper token validation is fundamental to preventing CSRF attacks. There's no such thing as a "simple" endpoint that doesn't need protection.

Lesson 2: Test What Seems Simple

Vulnerabilities often hide in endpoints that seem straightforward. The most critical data sometimes has the least obvious protections.

Lesson 3: Security Reviews Teach You About Priorities

Understanding how companies prioritize and classify vulnerabilities teaches you how to think about security holistically.

Lesson 4: Responsible Disclosure Works, Even Out-of-Scope

Not every finding is a bounty winner. But professional reporting and ethical practices build credibility that's worth far more than any single payout.

The Bigger Picture

This CSRF vulnerability is part of a broader lesson: security is a process, not a destination.

Even well-established platforms can have vulnerabilities in their API security. The key differentiator is:

How systematically you test
How responsibly you report
How professionally you engage
How much you learn from the process

About This Finding

Detail Information Reported : June 2026 Vulnerability: CSRF Validation Bypass Classification: Informational (by Swiggy Security Team) Status: Reviewed and classified by Swiggy Data Affected : User addresses (PII)

This finding was reviewed by Swiggy's security team in June 2026 and classified as Informational. Published for educational purposes demonstrating responsible disclosure practices and API security awareness.

#SecurityResearch #CSRF #CyberSecurity #API #ResponsibleDisclosure #AppSecurity #InfoSec #VulnerabilityResearch

Contents