Security and privacy is a core concept for Grammarly. Grammarly looks forward
to working with the security community to find security vulnerabilities in
order to keep our businesses and customers safe.
Rules for us
- We respect the time and effort of our researchers.
- We will respond within 3 business days.
- We will try to make a bounty determination after validating a legitimate security issue within 10 business days.
- We will not take legal action against you for playing by these rules.
- We will do our best to keep you informed about our progress throughout the process.
- We will not respond to threats or negotiate under duress.
Rules for you
- Be an ethical hacker.
- Respect other users’ privacy: only interact with Grammarly accounts you own or with the explicit permission of the account holder.
- Make a good-faith effort to avoid testing that would result in privacy violations, destruction of data or interruption or degradation of our service.
- Let us know as soon as possible upon discovery of a potential security issue.
- Contact us immediately if you do inadvertently encounter user data. Do not view, alter, save, store, transfer, or otherwise access the data and immediately purge any local information upon reporting the vulnerability to Grammarly.
- Follow disclosure guidelines __.
- We reserve the right to disqualify individuals from the program for disrespectful or disruptive behavior.
- We accept reports from hackers with a Signal higher than 1.0
Grammarly is particularly interested in testing our Native apps and clients,
Desktop Editors, Mobile Keyboards, Add-On for Microsoft Word and Outlook
Native apps and clients
Browser Extensions for Chrome, Safari, Firefox, Edge - A browser extension that 's compatible with the supported versions of Chrome, Safari, Firefox, and Edge.
Desktop Editors for Microsoft Windows and MacOS – our Electron-powered desktop application for macOS __and Windows __where users can write and manage their documents as well as configure account settings.
Add-On for Microsoft Word and Outlook - Grammarly add-on __for MS Word and Outlook for Windows.
Mobile keyboards and applications for Android and iOS – our mobile apps and keyboards.
WAF * - bugs leading to direct bypass of our firewall are eligible for focus scope bounty. Bugs that rely on hijacking cookies of our employees or using our employees ' devices as proxy don’t fall into this category.
All other assets listed in our “In Scope” table:
Exclusions from the scope:
anagram.grammarly.io - out of scope.
We’re already aware of certain issues found in
This service doesn't handle, store or transfer any internal data or data of
our users. Additionally, it is located in a separate VPC and isn't part of our
We accept only critical submissions (SSRF, XXE, SQLi, RCE) with a
clearly reproducible proof of concept code.
Reports that don 't match these criteria will be closed as "N/A".
Vulnerabilities are eligible for submission if they’re reproducible on any
version of Word/Outlook on Windows 7/10 with all latest security patches
applied. The vulnerability should be tested on a system without additional
SDKs and development kits. We cover your expenses (1 month) on a Word/Outlook
license if the report appears being valid.
- When duplicates (including internally known issues) occur, we only award the first report that we receive.
- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
- Our rewards are based on the impact of a vulnerability, attack requirements and scenario.
- We will try to conform with CVSSv3. However, certain exclusions might be possible.
- The final reward decisions are up to the discretion of Grammarly.
- We may calculate the severity and rewards of particular vulnerabilities in our client apps and web applications based on our User Agents and platforms statistics.
- Clearness of your report reflects the potential reward: If your report isn 't clear enough (e.g., lacks proof of concept code), it may lower the bounty, despite the severity of the found issue. This rule works vice versa too!
- If your report pointed our internal security team to a more severe bug, we will calculate your reward based on the most severe bug we found internally.
- Unusual bugs, tricks, or bypasses might be extra rewarded.
- A report might be rewarded retroactively for a limited amount of time on a case-by-case basis.
- We may award a Grammarly Premium account for particular "Informative" or "Low" severity bugs.
- We will increase the rewards for eligible reports if they are submitted in the form of
curl or puppeteer __scripts automating exploitation of the vulnerability (i.e., exploit) and contributed under the MIT license , which must be attached to the script. To be eligible for a bonus, your exploit must be attached before the bug is fixed.
Recommendations for reporting
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
- Multiple chained vulnerabilities submitted as one report will qualify for one bigger bounty. If you submit multiple linked vulnerabilities as different reports, we will award every vulnerability individually! Please, remember this.
- Reports that include proof of concept code will be more likely to be accepted.
- Include how you found the bug, the impact, and any potential remediation.
- Public disclosure of the vulnerability prior to resolution may cancel a pending reward.
- We reserve the right to not disclose the report or to disclose it only partially. (We may do this if the original report includes password hashes, config files, proprietary source code, any internal info, etc.)
- We encourage public disclosure of your findings in our program!
- We'd like to help out with your write-ups about publicly disclosed bugs. Feel free to send your write-up to email@example.com!
- Report about any vulnerability from the exclusion list below will most likely be closed as "N/A".
- Submitting multiple N/A reports may result in you being excluded from participating in our program.
Common vulnerabilities excluded from the scope:
- Social engineering (e.g., phishing, vishing, smishing) of Grammarly employees and users is strictly prohibited.
- Clickjacking on pages without demonstrable impact (e.g. account takeover).
- CSRF with minimal security implications (Logout CSRF, etc.)
- Content spoofing issues without showing an attack vector and without being able to modify both HTML and CSS.
- CSV injection.
- Previously known vulnerable libraries without a working Proof of Concept.
- Vulnerabilities in outdated versions of Grammarly software.
- Issues relating to buggy non-Grammarly client software.
- Stack traces, path disclosure, and directory listings.
- Vulnerabilities that rely on installed outdated third-party software (e.g. Windows 7, Flash, Java applets, and similar deprecated technologies) will be triaged as "Low" for critical actions and "Informative" for non-critical ones.
- Reports that affect only outdated user agents or app versions. We only consider exploits in the latest browser versions for Safari, Firefox, Chrome, Edge, IE and the versions of our applications that are currently in the app stores.
- Any activity that could lead to the disruption of our service (DoS).
- Attacks requiring physical access to a user's device.
- Reports that include only crash dumps or other automated tool output without a proof of concept code.
- Open redirect vulnerabilities that do not demonstrate a clear impact, such as sending secret tokens to an arbitrary domain are out of scope.
- Open ports scanning, banner grabbing, software version disclosure issues.
- MITM attacks on secure connection and “Mixed Content” issues are out of scope.
- Issues related to the missing address bar in Grammarly Desktop Editor. We’re aware of this issue affecting Electron apps serving web pages.
- Vulnerabilities that require root-level access on a targeted mobile device are out of scope.
Non-Qualifying best practices
- Missing cookie flags on non-authentication cookies.
- Missing best practices in DNS configuration (e.g. DKIM/DMARC/SPF/TXT).
- Missing best practices in SSL/TLS configuration.
- Missing best practices in Content Security Policy (CSP) or lack of other security-related headers.
- Leakage of sensitive tokens (e.g., reset password token) to trusted third parties on secure connection (HTTPS).
Non-Qualifying (business) issues
- Institution access code enumeration or demonstrating access codes leaked in Internet forums.
- Credential re-usage from public dumps.
- UUID enumeration of any kind.
- Ability to determine if a username or email has a Grammarly account, also known as an account oracle.
- Signing up with multiple accounts to abuse referral code usage.
- Password length, complexity, and re-use requirements.
- Email verification feature.
- Sharing Premium accounts with other users isn't considered a monetary impact.
Thank you for helping keep Grammarly and our users safe!
Consequences of Complying with This Policy aka Safe Harbor
We will not pursue a civil action or initiate a complaint to law enforcement
for accidental, good faith violations of this policy. We consider activities
conducted consistently with this policy to constitute “authorized” conduct
under the Computer Fraud and Abuse Act. To the extent your activities are
inconsistent with certain restrictions in our Acceptable Use Policy, we waive
those restrictions for the limited purpose of permitting security research
under this policy. We will not bring a DMCA claim against you for
circumventing the technological measures we have used to protect the
applications in scope.
If legal action is initiated by a third party against you and you have
complied with Grammarly’s bug bounty policy, Grammarly will take steps to make
it known that your actions were conducted in compliance with this policy.
Please submit a HackerOne report to us before engaging in conduct that may be
inconsistent with or unaddressed by this policy.
A note from our internal security team
Things we do like:
- Rewarding talented researchers with huge bounties.
- Extra-rewarding researchers for multiple "Medium"/"High" security issues.
- Easily reproducible PoCs (e.g., with curl).
- Clear Impact section in your reports.
Things we don't like:
- Speculative researchers and speculative reports.
- Violations of program rules.
- Theoretically exploitable issues without clear proofs of exploitability.
- Unethical hacking: saving/modifying/selling our data intentionally.
- Copy-pasted reports from the “public disclosure” section on HackerOne.
Where to start?
- The Office Add-in is a particularly interesting target.
- We especially like reports about our browser extensions.
- We have good CSRF protection.
- We are waiting for your XXE reports (don't forget a PoC).
- Our Electron app is already hardened with
- WAF is a great target for experienced web hackers.