The security and privacy of your data are our utmost concern. Lark abides by rigorous security policies, and implements robust systems to protect user data. We encourage security research individuals as well as teams to test our security, and we offer rewards for valid reported vulnerabilities. As we keep on adding new features, we encourage community researchers to keep working on our projects to find new vulnerabilities.

Response Targets

Lark Technologies will make a best effort to meet the following response targets for hackers participating in our program:

• Time to first response (from report submit) - 1 business days

• Time to triage (from report submit) - 3 business days

• Time to bounty (from triage) - 5 business days

We’ll try to keep you informed about our progress throughout the process.

Disclosure and Confidentiality Policy

We support public recognition and disclosure of contributions and findings for those participants who desire. We will seek to allow participants to be publicly recognized whenever possible. Public disclosure of a vulnerability (either full or partial) is allowed after being coordinated with Lark Team and disclosed on HackerOne. If 180 days have elapsed with the Lark Team not providing a vulnerability disclosure timeline, the contents of the report may be publicly disclosed by the reporter. Retention, copying, or disclosure of Lark information gained as a result of participation is not permitted.

If requesting beyond limited HackerOne disclosure (e.g. in a blog or at a conference), please share your blog post or presentation with us prior to the publication.

Program Rules

• You must be the first reporter to report the issue to us. We will only reward the first reporter.

• When submitting a vulnerability, please provide us with enough information so that we could reproduce and verify it.

• Please use your own account for testing purposes. Do not gain access to another user's account or their confidential information.

• Please do not test for denial of service, spam, social engineering issues.

• All of the tests must not violate any law, or compromise any data that is not your own.

• Please contact security@larksuite.com to report security incidents such as customer data leakage or breach of infrastructure

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

• Submit one vulnerability per-report, unless you need to chain vulnerabilities to provide impact.

• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).

• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

Testing and Guidance

Signing Up

• You may register up to two test accounts on https://www.larksuite.com/ for free

• You will be required to create a domain name for each account which you will be using to do your testing

Treasure Map and Lark Suite Product Guidance

To better understand the Lark Suite Product and its core functions, please refer to the updated Treasure Map 2.1 we have created: https://bytedance.feishu.cn/docs/doccnlT329U2f6EFPV5Bvqa0f3A#ZWfYX1

Bug Bounty Rewards Assessment

Typical bug bounty rewards range from $100 to $5,000, depending on their severity and asset tier. No upper limits

Rewards Range:

Critical vulnerabilities examples:

• SQL Injection, which could get massive customer information

• Remote code execution on server side

• Remote code execution on client app

• Remote user sensitive information disclosure on client app

• Privilege escalation affecting all users

• Broken authentication affecting all users

• SSRF to lark internal service, with extremely critical impact, such as being able to access internal sensitive data

• And other critical severity issues

High vulnerabilities examples:

• Privilege escalation affection part users

• Broken authentication affection part users

• SSRF to internal services of Lark

• And other high severity issues

Medium vulnerabilities examples:

• Privilege escalation affecting single user

• Broken authentication affecting single user

• XSS which could attack other Lark users

• Logical vulnerabilities affecting sensitive operations

• Remote denial of service or app crash

• Information disclosure of service(with customer data)

• Remote information disclosure on client app, like program memory, log, etc

• Insecure storage of sensitive information on client app

• And other medium severity issues

Low vulnerabilities examples:

• Information leakage(without customer data)

• Server misconfiguration or errors

• Local denial of service or app crash

• Local information disclosure on client app, like program memory, log, etc

• And other low severity issues

Please refer to the rewards section for the bounty table. Our bounty table provides general guidelines, and all final decisions are at the discretion of Lark. We reserve the right to accept and review any security report including for out of scope issues, but we will not award a bounty for out of scope issues in fairness to other researchers who are adhering to program scope. This will be true regardless of the severity of the vulnerability.

Known Issues

Please note that these known issues will not be eligible for bounties:

• Cross-Site Request Forgery (CSRF)

• Cross-Origin Resource Sharing (CORS)

• Clickjacking

We are working on a fix for the above issues and seek your kind patience.

Out of Scope Vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Reports from automated tools or scans

• False positive SQL Injection

  • To avoid submitting a false positive, please ensure that you are able to provide a working PoC that demonstrates the ability to retrieve the current database / current user name

• Spam vulnerability, mail spoofing, mail bomb, etc.

• Self-XSS

• Use of known-vulnerable library or component

• Clickjacking on pages with no sensitive actions

• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions

• Attacks requiring MITM or physical access to a user's device.

• Previously known vulnerable libraries without a working Proof of Concept.

• Comma Separated Values (CSV) injection without demonstrating a vulnerability.

• Missing best practices in SSL/TLS configuration.

• Any activity that could lead to the disruption of our service (DoS).

• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

• Rate limiting or brute-force issues on non-authentication endpoints

• Missing best practices in Content Security Policy.

• Missing HttpOnly or Secure flags on cookies

• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)

• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]

• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).

• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.

• Tabnabbing

• Open redirect - unless an additional security impact can be demonstrated

• Issues that require unlikely user interaction

• Vulnerabilities that are already known (e.g. discovered by an internal team)

• Best practice reports are not eligible for bounties but are appreciated.

• Exposure of Google Maps API Key.

Notes about IDOR Vulnerabilities

Researchers must be able to prove a feasible way to gain an ID as an attacker and we will not accept reports where IDs are being brute forced.

• Example: An ID is 19 characters long. To guess this ID, an attacker will have to calculate 10^19 combinations which is not in the range of an online brute force attack. IDOR vulnerabilities with access to unimportant data will also not be eligible for bounty.

Out of Scope bugs for Android apps

• Any URIs leaked because a malicious app has permission to view URIs opened

• Sensitive data in URLs/request bodies when protected by TLS

• Lack of obfuscation and binary protection

• Any kind of sensitive data stored in app private directory

• Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment & root permission)

• Shared links leaked through the system clipboard.

• Intent or URL Redirection leading to phishing

• Third party library 0day

Out of Scope bugs for iOS apps

• Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries

• Absence of certificate pinning

• Path disclosure in the binary

• User data stored unencrypted in the app private directory

• Lack of obfuscation is out of scope

• Lack of jailbreak detection is out of scope

• OAuth & app secret hard-coded/recoverable in IPA

• Crashes due to malformed URL Schemes

• Lack of binary protection (anti-debugging) controls

• Snapshot/Pasteboard leakage

• Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment)

• Third party library 0day is out of scope

• URL Redirection leading to phishing

Contacting the Lark Technologies Team

If you require any clarifications regarding the scope of the program (eg: potential Lark's user data leaking in one of our third-party vendors) or face specific challenges when testing, you may email the Lark Team at bugbounty@larksuite.com. Kindly also keep the Program Manager, muchfimuchfeelz@wearehackerone.com in the loop.

However, please do not escalate questions about the validity or bounties of your existing reports. Such emails will not be responded to and discussions should be done within the report itself. If you are unsure about a potential vulnerability, please submit the report to us and we will assess it accordingly.

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.