Under this policy, “research” means activities in which you:

• Notify us as soon as possible after you discover a real or potential security issue.
• Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
• Only use exploits to the extent necessary to confirm a vulnerability’s presence. Do not use an exploit to compromise or exfiltrate data, establish command line access and/or persistence, or use the exploit to “pivot” to other systems.
• You will not intentionally compromise the privacy or safety of Nykaa personnel (e.g. civilian employees or military members), or any third parties.
• You will not intentionally compromise the intellectual property or other commercial or financial interests of any Nykaa personnel or entities, or any third parties.
• Once you’ve established that a vulnerability exists or encountered any sensitive data (including personally identifiable information, financial information, or proprietary information or trade secrets of any party), you must stop your test, notify us immediately (within 24 hrs), and not disclose this data to anyone else.

In order to help us triage and prioritize submissions, we recommend that your reports:

• Adhere to all legal terms and conditions outlined in the policy and the Nykaa Bug Bounty Terms of Service.
• Describe the vulnerability, where it was discovered, and the potential impact of exploitation.
• Offer a detailed description of the steps needed to reproduce the vulnerability (proof of concept scripts or screenshots are helpful).

Security researchers must not:

• Test any system other than the systems set forth in the ‘Scope’ section above,
• Disclose vulnerability information except as set forth in the ‘Reporting a Vulnerability’ and ‘Disclosure’ sections below
• engage in physical testing of facilities or resources,
• engage in social engineering,
• send unsolicited electronic mail to Nykaa, including “phishing” messages,
• execute or attempt to execute “Denial of Service” or “Resource Exhaustion” attacks,
• introduce malicious software,
• test in a manner which could degrade the operation of Nykaa or intentionally impair, disrupt, or disable Max Healthcare systems,
• test third-party applications, websites, or services that integrate with or link to or from Nykaa data or render Nykaa data inaccessible, or,
• use an exploit to exfiltrate data, establish command line access, establish a persistent presence on Nykaa, or “pivot” to other Nykaa.

Security researchers may:

• View or store Nykaa nonpublic data only to the extent necessary to document the presence of a potential vulnerability.

Security researchers must:

• cease testing and notify us immediately upon discovery of a vulnerability,
• cease testing and notify us immediately upon discovery of an exposure of nonpublic data, and,
• purge any stored Nykaa nonpublic data upon reporting a vulnerability

All systems and services associated with domains listed below are in scope. Likewise, subdomains of each listing, unless explicitly excluded, are always in scope. Additionally, any website published with a link to this policy shall be considered in scope. Vulnerabilities found in non-federal systems from our vendors fall outside of this policy’s scope and should be reported directly to the vendor according to their disclosure policy (if any).

1. Vulnerabilities that do not demonstrate security impact will be considered out of scope for this program.
2. Vulnerabilities regarding SPF/DMARC/DKIM records without verifiable proof of spoofing 
3. Best practice concerns like non-session cookies not marked secure and HTTP only, SSL/TLS configuration, missing security headers, etc.
4. Vulnerabilities reported by automated tools and scanners without additional proof of concept
5. End of Life Browsers / Old Browser versions (e.g. Internet Explorer 6)
6. Denial of Service(DoS) and Distributed Denial of Service(DDoS) attacks
7. Exploits that need physical access to the victim’s device
8. Host header injection
9. Unauthenticated/logout/login CSRF
10. Previously known vulnerable libraries without a working Proof of Concept
11. Any kind of spoofing attacks or any attacks that lead to phishing (e.g. Email spoofing, Capturing login credentials with fake login page)
12. Self XSS
13. Bugs requiring exceedingly unlikely user interaction example Social engineering attacks, both against users or Nykaa employees
14. Third-party API key disclosures without any impact or which are supposed to be open/public. Specifically, exposed Google Map API keys and keys in Android XML files. 
15. OPTIONS / TRACE HTTP methods enabled
16. Known public files or directories disclosure (e.g. robots.txt, CSS/images, etc)
17. Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality
18. Any kind of vulnerabilities that require installation of software like web browser add-ons, etc. in the victim's machine
19. Brute force on forms (e.g. Newsletter / ContactUs page)
20. Missing best practices in Content Security Policy.
21. Missing SSL, CAA headers
22. Functional, UI, and UX bugs and spelling mistakes.

Android/IOS

1. Exploits that are reproducible only on rooted/jailbroken devices
2. Absence of certificate pinning
3. Bypassing root/jailbroken detection
4. Snapshot/Pasteboard/Clipboard data leakage
5. Lack of obfuscation
6. Irrelevant activities/intents exported
7. Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries in the IOS app
8. Lack of binary protection control

Carefully review and understand the rules and scope of the bug bounty program. Each program has specific guidelines, eligibility criteria, and a defined scope of systems, applications, or services that are in-scope for testing. Focus your efforts on these areas to ensure your findings are eligible for rewards.

When reporting a vulnerability, commit to providing clear and comprehensive details to help the organization reproduce and validate your findings. Include step-by-step instructions, proof-of-concept code if applicable, and any other relevant information that can assist the organization's security team in understanding and verifying the issue.

Engage in professional communication with the organization's security team. Be responsive to any requests for clarification, additional information, or coordination during the vulnerability verification process. Maintain open and respectful communication throughout the entire process, understanding that both parties are working together to improve security.

Always adhere to responsible disclosure practices. When you discover a vulnerability, avoid exploiting it for malicious purposes or sharing it with unauthorized parties. Instead, immediately report the vulnerability to the program organizers following the reporting process outlined in the program guidelines. This allows the organization to address the issue before potential harm can occur.

Researchers participating in our programs are expected to adhere to specific Safe Harbor provisions. They are assured Legal Protection; by complying with all program terms, they're granted a legal safe harbor, ensuring they won't face lawsuits or legal actions for their reported findings. Participants also commit to Responsible Disclosure, providing ample time to address and rectify vulnerabilities and doesn't disclose any findings publically what so ever. Testing should be confined only to systems they have explicit authorization to assess. Furthermore, during the assessment, data access should be minimized, focusing only on what's necessary to validate a vulnerability, and retaining no user data beyond what is absolutely required.