The FPL responsible disclosure programme

FPL takes the security of its customers, employees and technology very seriously. Whilst we build our systems to be as robust as possible, we greatly value the support of security experts around the world in helping us identify and eliminate any weaknesses.

If you think you’ve found a security flaw, we welcome the chance to work with you to resolve the issue. Please send a detailed report at security@fplabs.tech.

Please note that currently we don’t have any monetary program. We can offer goodies/swags if applicable.

Response Efficiency

Types of Response Metric/Description Target SLA in Business Days
First Acknowledgment Initial confirmation that your report has been received. Within 7 Days
— — —
Time to Triage Time from acknowledgment to initial assessment, validation, and prioritization of the vulnerability. This includes confirming reproducibility. 14 Days
— — —
Time to Resolution Time from triage to the implementation and deployment of a fix or mitigation for the validated vulnerability. This includes verification by our team. 28 Days
— — —
Swags/Goodies Dispatch Time from resolution of the vulnerability to the dispatch of applicable rewards. 28 Days
— — —

Eligibility

To qualify for a reward under this program, you must:

  • Be the first to report a specific vulnerability.
  • Send a clear textual description of the report along with steps to reproduce the vulnerability. Include attachments such as screenshots or proof of concept code as necessary.
  • Disclose the vulnerability report responsibly to us. Public disclosure or disclosure to other third parties - including vulnerability brokers - before we addressed your report forfeit the reward/point.
  • Demonstrate care in reproducing the vulnerability. In particular, test only on accounts you own and do not attempt to view or tamper with data belonging to others.

Non-qualifying vulnerabilities and exclusions:

The following types of reports are generally not eligible for recognition or are considered out of scope for this program:

  • API Key & Hardcoded Secrets Reports:
    • Reports that solely disclose API keys (including Firebase URLs/API keys) or other hardcoded/recoverable secrets (like OAuth or app secrets in IPA/APK files) without demonstrating a direct and clear security impact resulting from the key’s or secret’s exposure will not be accepted.
  • Social Engineering & Physical Attacks:
    • Social engineering attempts on our staff (including phishing, vishing, smishing, or opening support requests).
    • Attempts to access our offices or data centers or physical facilities.
    • Attacks requiring physical access to a user’s device (unless explicitly in scope) or modification of hardware.
    • Exploits that need Man-in-the-Middle (MITM) access to the victim’s device (unless it enables a severe impact beyond simple interception).
  • Low Impact / Informational Findings:
    • “Self” Cross-Site Scripting (XSS) and XSS without demonstrated security impact (e.g., self-exploitation, or bugs/attacks requiring extremely unlikely actions by a victim or extensive user interaction).
    • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions (e.g., Logout).
    • Clickjacking on pages with no sensitive information or sensitive actions.
    • Content spoofing and text injection issues without showing an attack vector or ability to modify HTML/CSS.
    • Missing HttpOnly, Content-Security-Policy (CSP), or Security Flags on cookies that do not directly lead to a vulnerability.
    • Reports solely indicating the lack of a possible security defense such as certificate pinning / SSL Pinning, or Exploit mitigations (e.g., PIE, ARC, Stack Canaries). We constantly make security improvements to our product offering.
    • Generic information disclosure (e.g., Stack trace, application or server errors, directory listings, path disclosures, software version disclosure / banner identification issues, path disclosure in binary, exposure of non-sensitive data on the device) without additional demonstrable impact.
    • Permissive CORS configurations without demonstrated security impact.
    • Open redirects, unless you can demonstrate additional security impact by chaining with other vulnerabilities (e.g., steal OAuth tokens, Server-Side Request Forgery (SSRF), etc.).
    • Content-Security-Policy (CSP) configuration opinions.
    • Optional email security features (e.g., SPF/DKIM/DMARC configurations or flags) without verifiable proof of spoofing to a major mail client.
    • Vulnerabilities from automated scanners without additional analysis or a working proof of concept that impacts business logic.
    • Tampering with the host header in the request that only results in a redirect to a safe domain.
    • UI/API vulnerabilities which have no impact on mobile application functionality.
    • Crashes due to malformed URL Schemes or Intents sent to exported Activity/Service/Broadcast Receiver if they do not lead to a direct security impact (e.g., data breach, privilege escalation).
    • Shared links leaked through the system clipboard.
    • Any URIs leaked because a malicious app has permission to view URIs opened.
    • Address bar / URL / domain spoofing in dApp browser without demonstrated higher impact.
    • Sensitive data in URLs/request bodies when protected by TLS (if the vulnerability is merely their presence and not their insecure exposure beyond TLS’s protection).
  • Authentication & Account Related (Specific Exclusions):
    • Password complexity issues.
    • Username enumeration on Forgot Password, Registration Page, and Login endpoints (including via signup and account & recovery forms).
    • All types of brute-force and/or credential stuffing attacks (with the exception of faulty or missed rate-limiting, which itself may be out of scope).
    • Two-factor authentication bypass that requires physical access to a logged-in device.
    • Session Timeout.
  • Abuse & Denial of Service (DoS):
    • Do not perform any network volumetrics attacks that adversely affect the reliability of FPL’s services, including but not limited to, DoS and DDoS (this is also an eligibility requirement).
    • Use of automated tools that could generate significant traffic and possibly impair the functioning of our application.
    • Issues that merely result in spam/annoyance without additional impact (e.g., sending emails without sufficient rate limiting).
    • Most issues related to rate limiting (including rate limiting leading to spam or sending mails), including reports that bypass rate limiting through changing of IP addresses / Device IDs.
    • Any other issues where testing may affect the availability of systems.
    • Attacks that are noisy to users or admins (e.g., spamming notifications or forms).
  • Known & Outdated Issues:
    • Vulnerabilities that are already known (e.g., discovered by an internal team).
    • Previously known vulnerable libraries without a working Proof of Concept (POC) demonstrating exploitation within our systems. CVEs for outdated software with Low or Medium severity impact won’t be considered for recognition without a working POC.
    • Vulnerabilities only affecting users of unsupported or end-of-life browsers or operating systems. We consider vulnerabilities only in the versions of our applications that are currently in the app store and exploits only in the latest browser versions.
    • Reports with mobile versions not downloaded from official sites listed in our scope.
  • Mobile-Specific Exclusions:
    • Vulnerabilities that require root/jailbreak of the device for exploitation.
    • Local access to user data when operating a rooted/jailbroken mobile device.
    • Lack of obfuscation/binary protection/root(jailbreak) detection or bypassing of root/jailbreak detection.
    • Bypass certificate pinning on rooted devices.
    • Lack of field-level encryption for PII data fields (unless it directly leads to an unauthorized data breach).
    • Insufficient Cryptography without demonstrable exploitation leading to sensitive data compromise.
    • Sensitive information retained as plaintext in the device’s memory (unless accessible without root due to a specific vulnerability).
    • Any kind of sensitive data stored in-app private directory (unless accessible without root due to a specific vulnerability).
    • Application-side CORS vulnerabilities (if the impact is solely due to permissive configurations without further demonstrated security impact).
  • Other Specific Exclusions:
    • Assets not owned by FPL Technologies Pvt. Ltd. (third-party assets).
    • Credential Leak Reports: Reports of internal credential leaks or credential leaks found in personal repositories, Dark Web URLs, or on sites like huntr.io and haveibeenpwned.com will generally not be eligible for a reward. However, exceptions may be made in cases where there is a demonstrable and direct impact to the organization, at the discretion of the FPL security team.
    • Document exposures are generally out-of-scope and are not eligible for a reward; however, this can differ from scenario to scenario depending on our discretion.

Submission Requirement:

Please provide detailed reports with reproducible steps, screenshots and any artifacts for us to independently validate the POC (Proof of Concept). If the provided report is not detailed enough to reproduce the issue. We may ask for further data, steps or technical details. Issues without this level or timely follow up to provide detailed POC information for your write-up may not be eligible for rewards.

Duplicate Findings:

Submit one vulnerability per report, unless you need to chain the vulnerabilities to provide a complete POC. When duplicates occur, we only award the first report that was reported earlier.