Bug Bounty Program

This program exclusively covers vulnerabilities in FYERS-owned, FYERS-operated, and FYERS-maintained online trading systems (Web & Mobile) and explicitly listed in-scope assets.

Only assets where FYERS has full technical control (source code, infrastructure, deployment pipeline) are eligible for bounty consideration.

In-Scope

• FYERS Trading Platform (Web & Mobile App)
• FYERS APIs part of trading platform

Out of Scope

1. Assets Not Owned or Managed by FYERS

Vulnerabilities in the following are strictly out-of-scope and not eligible for bounty:

• Third-party vendor platforms and managed services
• Partner-hosted or white-labelled systems
• Legacy, deprecated, or soon-to-be-decommissioned systems
• Internal corporate systems, Development environments, Project management platforms, HR systems, Marketing websites, Vendor infrastructure not owned or operated by FYERS
• Any domain/subdomain not explicitly marked as "In Scope"

2. Known or Accepted Issues

• Vulnerabilities already known internally or currently under revamp, refactor, or decommissioning, even if publicly accessible
• Findings pending migration to a new architecture
• Issues reported previously or tracked internally as part of product transformation

3. Prohibited Testing Techniques

• Denial of Service (DoS), resource exhaustion, or rate-limit bypass attempts
• Social engineering attacks
• Automated high-volume scanning
• Sending OTPs/messages/emails/SMS to other users
• Attempting to brute-force account credentials, 2FA codes, or client IDs
• Creating fake KYC documents or synthetic identities
• Any actions affecting live trading systems during market hours

4. Low-Impact or Non-Security Issues

The following are not considered security vulnerabilities:

• Functional/UI bugs
• Missing non-security headers
• Informational disclosures without impact
• Non-sensitive keys intended for public client-side usage
• Cookies without security flags unless leading to real exploitation
• Login enumeration without actual data exposure
• Report-only configuration flags or non-sensitive debug info

5. Duplicate Submissions

FYERS follows a first-valid-report policy:

• Only the first researcher to report a valid, reproducible, in-scope issue is eligible for a bounty.
• All subsequent reports of the same issue, root cause, or exploit path are marked as duplicates.

• Submissions must be reported only through the official Bug Bounty form.
• A valid submission must include:
  • Clear and reproducible steps
  • Impact explanation
  • Proof-of-Concept (PoC)
  • Screenshots or video evidence with accessible permissions
• Submissions must not be publicly disclosed before FYERS resolves the issue.
• Proof-of-Concept must:
  • Use only the researcher’s own account
  • Avoid bulk data extraction
  • Avoid modifying production trading data
  • Demonstrate minimum interaction required to prove impact
• Attack Chain Validation
  • Where a submission relies on multiple conditions or a chained attack scenario, each prerequisite must be independently demonstrated and reproducible during our validation.
  • Severity will be determined based on the validated end-to-end impact, not on hypothetical, assumed, or speculative outcomes.
  • Reports that depend on phishing, malware, social engineering, browser extensions, prior credential compromise, authenticated session compromise, or another independent vulnerability will be evaluated only on the security impact of the reported issue itself.
• Demonstrated Impact Requirement
  • The reported impact must be practical, reproducible, and independently verifiable by the FYERS Security Team.
  • Severity will be assigned based on the impact demonstrated during validation, rather than on theoretical consequences or potential attack chains.
  • Claims such as "could lead to account takeover", "could leak sensitive data", or "could enable trading compromise" must be supported by a practical, reproducible exploit demonstrating the claimed impact.

Submission Review & Response Timeline

To ensure every submission receives an appropriate technical review, FYERS follows a structured triage process.

• Initial Triage: We aim to acknowledge and perform an initial review of all eligible submissions within 72 hours of receipt. Response times may vary depending on submission volume, severity, complexity of the report, requirement for internal validation, and engineering backlog.
• Technical Validation: Some reports require detailed investigation, reproduction, coordination with engineering teams, or assessment of business impact. During this period, we may request additional information from the researcher where necessary.
• Remediation: For reports accepted as valid, remediation timelines are determined based on the validated severity, business impact, regulatory requirements, and release schedules. While we aim to address eligible findings within 10 business days where feasible, more complex issues may require additional time. Critical vulnerabilities may be addressed on an expedited basis.
• Status Updates: Where appropriate, we will provide updates during the triage and remediation process. We appreciate your patience while our teams complete the necessary investigation.

Rewards are determined solely at FYERS' discretion based on severity, impact, exploitability, compensating controls, and regulatory risk.

Reward Bands:

Once a submission is accepted and FYERS requests an invoice, the researcher must submit the invoice within 15 days. Invoices not submitted within this period will result in the bounty being forfeited, and the submission will be closed with no payout.

Participants must:

• Keep all findings strictly confidential until resolved
• Not identify FYERS publicly without explicit approval
• Not share PoCs, logs, screenshots, or sensitive information with any third party
• Not reference FYERS in any public or private forums without written consent
• Not disclose any vulnerability or submission externally - even after it is fixed - under "responsible disclosure," "coordinated disclosure," or any similar justification unless FYERS provides explicit written approval

Violation may result in disqualification, banning from the program, or legal action.

Additionally, the following actions will result in immediate disqualification and potential legal escalation:

• Accessing or attempting to access other users' trading accounts
• Executing trades on behalf of another user
• Extracting bulk PII
• Attempting to monetize findings prior to resolution
• Public disclosure without authorization

Participants must:

• Comply with all Indian laws and cyber regulations
• Not attempt unauthorized access to personal data, financial data, wallets, trades, or order systems
• Immediately delete any sensitive information inadvertently accessed
• Avoid disruptions to production trading, market operations, or regulatory workflows

FYERS provides no "safe harbor" protections for activity deemed unlawful under Indian law.

FYERS is not responsible for any damages resulting from participation.

Participants agree to indemnify FYERS against claims arising from violation of these terms.

Acceptance, validation, or reward of a submission does not constitute admission of legal liability, regulatory breach, or systemic failure by FYERS.

Severity classification and bounty determination are internal risk assessments and do not imply regulatory non-compliance.

FYERS reserves the right to reject any submission, including but not limited to:

• Out-of-scope assets
• Third-party systems
• Low/no-impact issues
• Non-reproducible findings
• Issues already known or under revamp
• Violations of testing guidelines
• Duplicate submissions

All decisions on eligibility, severity, and payout are final.

FYERS may modify, pause, or terminate the bug bounty program at any time without notice.

These terms are governed by the Laws of India. Courts of Bengaluru Urban shall have exclusive jurisdiction.

For general queries about the FYERS Bug Bounty Program, please reach out to:

📧 [email protected]

All vulnerability submissions must be made exclusively through the official submission form to ensure proper triage, tracking, and compliance:

🔗 Submit Vulnerability via Zoho Form

Submissions sent through email, social media, or other channels will not be considered valid for bounty evaluation.

Severity determination is made solely by FYERS based on this rubric and is not subject to negotiation. FYERS may reference CVSS scoring; however, final severity is determined based on trading-system context and regulatory exposure rather than CVSS score alone.

Additionally, the following conditions automatically reduce severity:

• Requires victim interaction + social engineering
• Requires prior credential compromise
• Requires device-level compromise
• Requires attacker-owned account only
• Limited to pre-auth informational disclosure

FYERS Bug Bounty Severity Classification

General Principles

All submissions are independently assessed based on exploitability, demonstrated security impact, reproducibility, affected asset scope, and compliance with the FYERS Bug Bounty Program. Examples below are illustrative and not exhaustive. Inclusion of an example under a severity category does not automatically qualify a submission for a bounty.

Theoretical attack chains, speculative impacts, or findings requiring prior compromise of credentials, authenticated sessions, phishing, malware, social engineering, or another independent vulnerability will not be used to increase the severity of a report.

CRITICAL Severity (Up to ₹1,00,000)

Definition

A demonstrated vulnerability resulting in practical compromise of customer accounts, trading operations, regulated customer data, or FYERS backend infrastructure.

Critical findings must be independently reproducible and must not rely on phishing, social engineering, prior credential compromise, malware, or victim interaction.

Examples

Account Takeover

• Authentication bypass
• Login + OTP bypass
• Password/PIN reset of another user
• Theft of reusable trading session tokens
• Complete authentication bypass

Unauthorized Trading

• Place, modify or cancel another user's orders
• Unauthorized access to Holdings
• Positions
• Funds
• Order Book
• API token compromise enabling trade execution

Regulated Customer Data

• PAN disclosure (unmasked)
• Aadhaar disclosure (unmasked)
• BO/DP ID exposure (unmasked)
• Large-scale PII disclosure violating SEBI or DPDP

Financial Impact

• Unauthorized withdrawals
• Server-side payment secret compromise
• Payment manipulation (server side)
• Settlement compromise

Platform Availability

• Trading engine DoS
• Market-hour disruption
• Order queue manipulation

Mass User Impact

• Broken Access Control exposing multiple users
• Bulk customer data extraction

Infrastructure

• Backend Remote Code Execution
• Cloud takeover
• Database compromise
• Administrative access

HIGH Severity (Up to ₹50,000)

Definition

Validated vulnerabilities affecting a single user that result in meaningful confidentiality, integrity or availability impact.

The impact must be practically demonstrated.

Examples

Sensitive Information Disclosure

• Pre-auth disclosure of sensitive customer information
• KYC stage disclosure
• Correlated customer identifiers

Availability

• Pre-auth account lockout
• OTP abuse causing account denial-of-service
• Single-user trading disruption

Access Control

• Viewing another user's profile
• Viewing another user's settings
• Viewing watchlists
• Viewing sensitive logs

Business Logic

• Workflow manipulation impacting trading
• Trading state inconsistency
• Authorization flaws with customer impact

Authenticated Client-Side Code Execution

• DOM XSS or postMessage abuse resulting in authenticated account compromise or demonstrable sensitive data exposure.

MEDIUM Severity (Up to ₹20,000)

Definition

Validated vulnerabilities requiring additional conditions or having limited customer impact.

Examples

Authorization

• Reading non-financial customer information
• Limited IDOR
• Non-critical Broken Access Control

Token Issues

• Pre-auth token reuse
• Signup/request_key lifetime issues
• Scoped token misuse without privilege escalation

Client-Side Injection

• Stored/Reflected/DOM XSS where arbitrary JavaScript execution is demonstrated but no authenticated account compromise is proven.

Business Logic

• Limited workflow manipulation
• Single-user data inconsistency

Publishable Keys

• Publishable payment/API keys only where accompanied by a validated security impact.

LOW Severity (Up to ₹5,000)

Definition

Validated security weaknesses with limited practical security impact.

Examples

• Validated server-side open redirect with no demonstrated account compromise.
• Low-impact authorization issue without access to regulated or financial data.
• Low-impact information disclosure requiring authenticated access.
• Minor business logic issue with demonstrable security impact.
• Security misconfiguration with proven but limited exploitability.

INFORMATIONAL / HARDENING (NO BOUNTY)

Definition

Observations, defence-in-depth recommendations, product improvements or deviations from security best practices that do not demonstrate an exploitable security impact.

These may be tracked internally but are not eligible for bounty.

Product Behaviour

• UI/UX issues
• Layout/rendering problems
• Long text causing UI overflow
• Client-side validation bypass without security impact
• API naming or response consistency

Security Hardening

• Missing security headers
• CSP recommendations
• MTA-STS
• CAA
• Referrer-Policy
• Permissions-Policy
• Cookie attribute improvements without exploit
• OTP flow consistency
• Signup token cleanup

Non-sensitive Information Disclosure

• Version numbers
• Build metadata
• Environment flags
• Debug messages
• Public OAuth Client IDs
• Publishable Firebase / Google / Razorpay keys
• Public configuration intended for client applications

Legacy Assets

• Deprecated endpoints
• Legacy documentation
• Sample applications
• Static content
• Beta assets
• Unused APIs

Rate Limiting

• Missing throttling without demonstrated brute force
• OTP resend observations
• Enumeration without measurable impact

Mobile Findings

• APK decompilation
• iOS binary unencrypted
• Debug classes
• Stack traces without sensitive data

NOT ELIGIBLE / NO BOUNTY

The following are not considered security vulnerabilities under the FYERS Bug Bounty Program.

Expected Behaviour

• Intended application functionality
• Business decisions
• Product workflows
• Client-side redirects
• Browser behaviour
• OAuth flows functioning as designed

Findings Requiring Independent Compromise

Reports where impact depends on:

• Prior credential compromise
• Authenticated session compromise
• Malware
• Browser extensions
• Social engineering
• Phishing
• XSS not reported as part of the same submission
• Any other independent vulnerability

Functional Defects

• Display issues
• UI overflow
• Form validation inconsistencies
• Client-side maxlength bypass
• Cosmetic defects
• Functional bugs without security impact

Unsupported Impact Claims

• Theoretical attack chains
• Speculative privilege escalation
• Assumed account takeover
• Hypothetical cookie theft
• Claims not independently reproducible