Responsible disclosure, a DOM-Based XSS on an authentication domain, and a certificate signed by the security team. This is the story behind it.
On May 1st, 2026, I received a Certificate of Appreciation from the security team of one of India's largest payment platforms — certificate number BBCERT #11000000206, signed and dated, recognizing my efforts in responsible security vulnerability disclosure.
This post is not about the certificate. It is about what it took to get there and what responsible disclosure actually looks like in practice.
The Finding
The vulnerability was a DOM-Based Cross-Site Scripting vulnerability on the platform's OAuth login page. The login page accepted a parameter called baseUrl directly from the URL and used it to dynamically load a JavaScript file — with no validation, no domain allowlist, and no Content Security Policy in place.
By supplying a malicious baseUrl pointing to an attacker-controlled server, an external script would be fetched and executed in the context of the authentication domain. The attack required no authentication and was delivered entirely through a crafted URL — making it a one-click attack against any user who received the link.
Because this executed on the authentication domain handling phone numbers, OTPs, and OAuth tokens, the potential impact included credential interception, OAuth flow manipulation, and full account compromise.
The Process
Finding the vulnerability was step one. Reporting it responsibly was step two — and equally important.
The report included a clear description of the vulnerability, the exact steps to reproduce it, the root cause analysis, and a detailed impact assessment. Everything was documented with the assumption that the security team needed to reproduce and validate it without any back and forth.
The response came through the bug bounty program. The team reviewed the finding, validated the impact, and acknowledged the responsible disclosure.
On May 1st, 2026 — the certificate arrived.
What Responsible Disclosure Actually Means
A lot of people in security talk about responsible disclosure without practicing it. Here is what it actually looked like on this engagement:
Report only, never exploit. The vulnerability was demonstrated with a proof of concept that confirmed execution — an alert showing the authentication domain. Nothing beyond that. No credential harvesting, no session hijacking, no further testing of the attack chain on real users.
Document everything. Screenshots, request and response details, root cause, impact assessment, remediation recommendations. A well documented report gets taken seriously. A vague report gets deprioritized.
Give them time. After submission, the security team needs time to validate, assess, and fix. Rushing them or going public before a fix is irresponsible. The disclosure timeline was respected completely.
Accept the outcome. Bug bounty programs define their own scope and severity. The outcome — a certificate of appreciation rather than a monetary reward — is still a legitimate acknowledgment of the finding and the effort.
Why This Matters Beyond the Certificate
A Certificate of Appreciation from a major payment platform security team is a credential. It is documented proof that you found a real vulnerability, reported it responsibly, and were recognized for it by the organization's security team.
For anyone building a career in offensive security — certificates, hall of fame acknowledgements, and responsible disclosure history are part of your professional record. They show up in job applications, freelance profiles, and bug bounty reputation scores.
The finding mattered. The process mattered. The documentation mattered.
That is what the certificate represents.
The Lesson
The best bug bounty hunters are not just technically skilled. They are professional. They communicate clearly, document thoroughly, respect timelines, and treat the security team on the other side as a partner — not an adversary.
Responsible disclosure is not a formality. It is the difference between being recognized as a security researcher and being treated as a threat.
This certificate is proof that the approach works.
Certificate: BBCERT #11000000206 Issued by: Paytm Security Team Date: May 1st, 2026 Vulnerability: DOM-Based XSS — OAuth Login Page Disclosure: Responsible — via bug bounty program

full write-up:
Tags: Bug Bounty API Security Cybersecurity Ethical Hacking Web Security