Program guidelines

Introduction

Thanks for your interest in the 1Password bug bounty program! External security evaluations are an important step on our journey to make (and keep) 1Password the best and most secure password manager on the market. Please Note: Program information for the $1 million Capture the Flag (CTF) Challenge is specific and outlined in CTF Challenge section below.

Program highlights

Fast PaymentEnsures payment within 1 month of receiving a vulnerability report. [https://docs.hackerone.com/en/articles/8490833-security-page#h_9c1fc6b7c0](

)

Gold Standard Safe HarborAdheres to Gold Standard Safe Harbor. [https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement](

)

Top Response EfficiencyThis program's response efficiency is above 90%. [https://docs.hackerone.com/en/articles/8490880-response-target-indicators](

)

Collaboration EnabledIncludes Retesting

5 days, 21 hours Average time to bounty

5 days, 21 hours Average time from submission to bounty

Rewards summary

Last updated on December 3, 2024. [/1password/bounty_table_versions](View changes

)

Each severity lists the 90-day average bounty and the percentage of total resolved reports, if applicable.

LowAvg. bounty $300

MediumAvg. bounty $600

HighAvg. bounty $6,000

CriticalAvg. bounty n/a

LowAvg. bounty $300

MediumAvg. bounty $600

HighAvg. bounty $6,000

CriticalAvg. bounty n/a

$50–$300

$300–$600

$600–$6,000

$6,000–$30,000

Scope exclusions

Core Ineligible Findings are out of scope. [https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](Learn more

)Category Exclusion details

General Exclusions (1) 1Password won’t accept submissions or reports for: Scheduled infrastructure changes

General Exclusions (2) 1Password won’t accept submissions or reports for: Any attack that requires root access

Vulnerability Definition (1) We may reject reports of bugs that meet these criteria, or downgrade priority: Bugs that don’t compromise account, user, vault, or item security

Vulnerability Definition (2) We may reject reports of bugs that meet these criteria, or downgrade priority: Bugs that require direct memory access or dynamic instrumentation

Vulnerability Definition (3) We may reject reports of bugs that meet these criteria, or downgrade priority: Bugs caused by operating system virtualization or emulation

Vulnerability Definition (4) We may reject reports of bugs that meet these criteria, or downgrade priority: Bugs that depend on memory dumps or tools that read active or cached memory

Commonly Reported Issues These issues have been reviewed numerous times and reached the conclusion that the product design is what we want it to be, or that they are inapplicable based on the published White Paper. Reports for these items will be marked "not applicable." See the full list in "Out of scope findings" below.

Placeholder or Template Submissions Placeholder or templated reports (e.g. no detailed replication steps or templated information in the initial report, etc) will be marked "not applicable." All valid findings must be submitted with a full description, proof of concept, and complete replication steps in the initial submission.

Platform standards deviations

This program has not committed to the following Platform Standards. As such the report severity or outcome may differ.

Severity rating for leakage of sensitive personally identifiable information We will consider a vulnerability in this class to be considered "Critical" in cases where 1Password is solely responsible for the security of the data. Often our users can accidentally leak their own data through various means including, but not limited to, uploading Emergency Kits on publicly shared systems, utilizing tools such as VirusTotal to scan emails, and similar. Additionally it should be noted that users are responsible for the security of the devices they trust when signing into their accounts, and 1Password performs a best effort approach to local threats.
Severity rating for vulnerabilities involving a self-sign-up flow Self sign-up is possible for net new accounts, but not possible for users being added to existing accounts. We will consider "Privileges Required" to be set to "None" in cases where a vulnerability is exploitable without logging into the victim's 1Password account or if a local attack requires no privileges on the device to exploit. Check https://docs.hackerone.com/en/articles/8369826-detailed-platform-standards#h_e01bc643a8 for the full Platform Standards page list.

Overview

Last updated on August 15, 2025. [/1password/policy_versions](View changes

)

Get started

This isn’t an easy program — scanners are unlikely to help, and standard XSS-type injections won't yield much either. We need creative researchers who aren’t afraid to think outside the box. We're happy you're here.

Start with the [http://1pw.ca/whitepaper](1Password Security Design White Paper), and pay particular attention to the section titled Beware of the Leopard (page 68). It explains the decisions and considerations behind the 1Password security design. We’ve also [https://github.com/1Password/burp-1password-session-analyzer](created a tool) to help you investigate http://start.1Password.com requests and responses with your own session key.

Get help

For information about the internal API, general questions, and to submit partial reports and theories, please send an email to mailto:[email protected] so we can collaborate, provide support, and offer appropriate guidance.
Assistance isn’t guaranteed for complex and/or time-consuming requests.
We’ll accept flaw-hypothesis submissions without penalty, and work with you to develop a reasonable hypothesis when possible.

Capture The Flag Challenge

We introduced a $1 million CTF bug bounty challenge in 2022 to further our commitment to providing an industry-leading security platform for individuals, families, and businesses. Interested in participating? Join our [https://hackerone.com/1password_ctf](dedicated HackerOne program).

Response Targets

1Password - Enterprise Password Manager will make a best effort to meet the following SLAs for hackers participating in our program:

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

Disclosure Policy

Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. This includes all submitted vulnerability (duplicate, not applicable, etc).
Follow HackerOne's [https://www.hackerone.com/disclosure-guidelines](disclosure guidelines).

Program Rules

Automated requests/scanning must be kept to under 45 requests per minute.
Scanners (and anything that sends an excessive number of requests) will add wait time to your tests due to the rate limiting that is in place.

1Password applications are designed with multiple layers of security measures. Intentionally bypassing established measures generally leads to a temporary block from our services, for approximately 24 hours. We typically enforce suspensions for their defined periods, as policy dictates; particularly suspensions that result from conduct that violates our program rules. We acknowledge there may be situations in which a researcher feels a block has been implemented unjustly — during the course of regular application use, for example. In such cases, we encourage you (the researcher) to [mailto:[email protected]](contact us via email). Although we cannot guarantee the removal of your suspension, communicating your concerns will ensure your case is heard as each scenario is evaluated individually. We appreciate your understanding and help maintaining the integrity and security of 1Password.

Only detailed reports with reproducible steps are considered valid and eligible for reward.
Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
The first valid report we receive will be rewarded in the event of duplication.
Multiple vulnerabilities caused by a single issue will be awarded one bounty.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
Only interact with accounts you own or for which you have explicit permission from the account holder.
[mailto:[email protected]](Contact us) to report tests that may cause a spike in errors or disrupt service so we can discuss other options.

Rewards

Our rewards are based on impact to account, user, vault, or item security with reports compromising multiple users on a wider scale increasing severity (e.g.; a local attack with malware is considered lower severity over a remote attack through our web application, while local attacks that can bypass authentication are higher severity than those that require 1Password to be unlocked to exploit). Please note these are general guidelines, and reward decisions are up to the discretion of 1Password.

Critical | High | Medium | Low | $6000 – $30000 | $600 – $6000 | $300 – $600 | $50 – $300 |

Out of scope findings

** All reports for out of scope findings will be marked as "Not Applicable" and the researcher will lose points. Please review our out of scope findings carefully.**

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug.

[https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](Core Ineligible Findings) are out of scope and won’t be rewarded. Please visit the list of [https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](core ineligible findings) for more information.

In order to be a triaged issue a submission must demonstrate an impact that can have an effect on our users. Submissions should always answer the question "as an attacker I could", with a suitable demonstration of such. Findings that disclose points of information or security best practices without an impact are not eligible for a reward and should be explored further in order to demonstrate risk.

We receive a number of common issue reports when new researchers are added to the program. These issues have been reviewed numerous times and reached the conclusion that the product design is what we want it to be, or that they are inapplicable based on the published [http://1pw.ca/whitepaper](White Paper). Below are these issues:

Issues Name/Category | Reasoning | SPF/DKIM and other email forgery protection | SPF/DKIM and other mechanisms are designed to offer hints to spam filters on receiving systems. In particular SPF pass or fail is not a very reliable indicator of authenticity or forgery. As such there is a fair amount of variation in how both senders and receivers may wish to configure it. Although we welcome suggestions and opinions about its tuning, we do not consider disagreements about that as “bugs”. | Disclosure of Session Tokens and UUIDs | As explained in the [http://1pw.ca/whitepaper](Security Design White Paper), UUIDs are not sensitive within the 1Password ecosystem. | Locally exposed Secret Keys | The Secret Key is meant to add entropy to 1Password's encryption for data stored on 1Password's servers. Locally on devices, your account password protects access to your vaults. See the [http://1pw.ca/whitepaper](1Password Security Design White Paper) under the section titled "Locally exposed Secret Keys.” | Browser-specific “Local Storage” Use for Secret Keys | Local storage is considered one of the safest options in today's browser technology, and is really only susceptible to cross-site scripting (XSS) attacks, of which you'll find none in the 1Password app! However, we've been very transparent about what would happen if an attacker were to obtain the Secret Key anyways, and that is where the Account Password comes in to protect the user's passwords and sensitive data on the device. Since both the Secret Key and Account Password are used to encrypt the data, obtaining the Secret Key is not enough to decrypt the data. | Rate limiting | We have high rate limiting due to needs from large enterprise organizations where many users access our products. Our team reviews our limits regularly and we are happy with them. In security we often have to balance between security and usability. Please additionally note in our rules: "Automated requests/scanning must be kept to under 45 requests per minute." and Denial of Service issues are considered out of scope. | Bypassing Rate limiting with IP rotation | While an attacker can rotate their IP address to bypass our current defenses there are many different considerations we have to take into account when thinking about rate limiting. In security we often have to balance between security and usability. In this specific case, CAPTCHA is not supported on all of the various clients we publish 1Password applications to. Additionally, there are privacy implications to consider. Embedding CAPTCHA into our application would put a third-party into a critical path within our application. With privacy and usability in mind, we are not looking to implement CAPTCHA at this time. | Ability to see content after Account Password change | The ability to see content in the application under the listed circumstances is actually due to a feature within our product that enables syncing and offline access. While the data is available, it is only what was previously stored on the device and no new items will be synced until full reauthentication occurs. Every device connected to a 1Password account will have a local cache of all vault data that is encrypted with the Account Password + Secret Key (along with a couple of other things). For users with cases such as a lost/stolen device, we recommend regenerating the Secret Key. | No prompt for Secret Key after deauthorizing a mobile device | Mobile devices (iOS and Android) store the Secret Key with OS-specific mechanisms for backup purposes. This means it is still accessible after deauthorizing a device. For users with cases such as a lost/stolen device, we recommend regenerating the Secret Key. | Known limitations with allowing offline syncing | The ability to see content in the application under certain circumstances (such as a device being offline when a user or device is removed) is actually due to a feature within our product that enables syncing and offline access. While the data is available, it is only what was previously stored on the device and no new items will be synced until full reauthentication occurs. Every device connected to a 1Password account will have a local cache of all vault data that is encrypted with the Account Password + Secret Key (along with a couple of other things). [https://1password.community/discussion/101453/changed-secret-key-still-able-to-access-vault](Here is a thread) that has several responses from our team that better explain the syncing and the security tradeoffs. For users with cases such as a lost/stolen device, https://support.1password.com/lost-device/#regenerate-your-secret-key-and-deauthorize-the-lost-device are some additional threads and documentation that would assist you with understanding those scenarios. | Client-based Access Controls | “[https://support.1password.com/permission-enforcement/#client-enforced-permissions](Client-enforced policy)” can be circumvented by a malicious client or determined user. | URLs, Emails, and Tokens (or other data) exposed in Wayback Machine or similar third-party tools | This problem is not something that we have direct control over unfortunately. We already have a strict robots.txt in place, located at https://start.1password.com/robots.txt, but many services tend to ignore it. This is doubly so when URLs are manually submitted to scanning services and the like by individuals not affiliated with 1Password. However, we do believe that we can improve on the situation by working to remove this PII from the URLs entirely, which should prevent archival services from recording user email addresses in the future. Since this issue has already been reported, we will not accept new submissions on the topic. Please note that other Tokens and UUIDs found to be recorded through these services are not considered sensitive which is why they will not be addressed. | Weak Password Policy | The current password policy is deliberately set to what it is, and there are no plans to change it. Note that in order to compromise an account you would need to have the Account Key in addition to the Account Password. Generally Account Password Strength is left up to the customer as the architecture of our application protects the vault data off-device by also leveraging the Secret Key in addition to the Account Password itself when encrypting the data. In this way, the Secret Key adds a considerable amount more entropy to the security of the data over the Account Password only. | Disclosed Banlist (“/banlist/combined_words.txt”) | This list is public by design, as it represents a list of banned words which aren't allowed to be used as passwords. If the security of our password strength meter or password generator depended on the secrecy of their design, that would mean that the design is insecure. | Hyperlink Injection in Emails | We often get researchers who report that they are able to inject hyperlinks into our emails. This is not our templates allowing this but instead is the email client that converts these into hyperlinks. Additionally the situations where this is "possible" do not result in situations that put account, user, vault, or item data at risk. Findings in this category that do not demonstrate a true impact in this area or violate the [https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](core ineligible findings) list will reconsidered not applicable. | Billing-related issues or ways to extend trials, use frozen accounts, etc | Issues within our billing system that allow users to circumvent billing limits (e.g.; license counts), extend trials or use frozen accounts are not considered to have a security impact on account, user, vault, or item data. Therefore these issues are considered out of scope to the program. | data-fcm-api-key exposure | This API key is intended to be exposed publicly. data-fcm-api-key is the Firebase Cloud Messaging (FCM) API key. You can read more about this key in the [documentation] (https://firebase.google.com/docs/projects/api-keys): Unlike how API keys are typically used, API keys for Firebase services are not used to control access to backend resources. | Multifactor Authentication | With 1Password, MFA is about device trust. MFA is not required upon every sign-in, but only once on every new device that has been set up. As a result, considerations that apply to other MFA implementations don’t necessarily translate to our MFA design. The reason that 2FA is only requested once for the apps is because of the role that authentication plays in your use of 1Password. When you first set up a new device you'll be asked to sign in and authenticate (using 2FA if you've set it up), once authenticated the 1Password app downloads a copy of your data to the device so that it isn't reliant on a connection to 1Password.com for you to be able to use your data. This data is kept encrypted and requires your password (or biometric unlock, if you've set that up) to decrypt it. At this point there isn't any authentication taking place, it's about decryption - so whilst we could prompt for 2FA, it would only be (what our Principle Security Architect calls) security theatre, it wouldn't stop an attacker who knew what they were doing from capturing your encrypted data. The security of your data comes not from the authentication, but from the encryption - making a strong password a key part of your defenses. | Uploaded Files - No scanning for “malicious” files | Files uploaded as vault items are encrypted as blobs prior to being sent to the server, so there is no risk of execution on the server itself. Within the client apps, no functionality executes the files that have been uploaded as vault items, and therefore the client app itself is not at risk. Just like receiving emails with attachments, users are responsible for having confidence in the origin of items that are shared with them. | Keeping and securing the emergency kit | Users are responsible for the security of their emergency kit and other information about their account that is solely in their hands (e.g.; secret key and account password). | Browser Autofill Security | 1Password generally considers the security boundary of Autofill to be the action of filling your items. After you decide to fill your information, the responsibility of that item’s security transfers to you. Please review the [https://support.1password.com/browser-autofill-security/](security boundaries of our autofill design). Reporting issues regarding autofilling non-login items into iFrames or other similar issues listed in the article will be considered out of scope. Clickjacking the autofill action for all items has already been reported and will not be reconsidered at this time. | Unclaimed NPM Packages | Dependency confusion does not automatically apply to private packages. Reports about unclaimed NPM packages require that people treat the specified private package as an NPM package. Most of the private packages seen publicly in various 1Password code repositories are not intended as an NPM package, and we never tell people to npm install that package. Therefore, they are not susceptible to the dependency confusion attack you describe. If a researcher chooses to report this issue, the original submission must include evidence that people are instructed to run npm install on that private package otherwise the report will be marked "Not Applicable." | Revealing who is registered | As outlined in our Security Design whitepaper: "If Oscar suspects that mailto:[email protected] is a registered user in a particular Team or Family it is possible for him to submit requests to our server which would allow him to confirm that an email address is or isn’t a member of a team." Note that this does not provide a mechanism for enumerating registered users; it is only a mechanism that confirms whether a particular user is or isn’t registered. Oscar must first make his guess and test that guess. We had attempted to prevent this leak of information and believed that we had. A difficult to fix design error means that we must withdraw from our claim of that protection. | CSV Injections | We have decided to follow the OWASP guidelines for determining when it is appropriate to fix CSV Injection. When a spreadsheet is used for data interchange (e.g.; vault or item data exports which can be imported) then we will not escape the characters which runs the risk of causing data integrity issues. In cases where an export is specifically for the purposes of being viewed in a spreadsheet program (e.g.; usage and member list exports) we’ll consider it an issue. Please also refer to [https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](HackerOne's Core Ineligible Findings) for additional notes about CSV Injections. |

Security must be balanced with usability

We’ll always consider feedback about design decisions but ask that you understand 1Password has been extensively reviewed by our internal team and external audits.

Additional Information

Download the [https://1password.com/downloads/](latest stable version) of 1Password or find the Beta versions detailed in our [https://releases.1password.com/](release notes.)

If you’re interested in testing our nightly build, you can install the nightly release as follows:

Open and unlock 1Password.
Click your account or collection at the top of the sidebar and choose Settings.
Click Advanced, then set “Release channel” to Nightly.

Updates will be installed automatically when “Install updates automatically” is turned on.

Note: Issues found in nightlies may be evaluated differently than issues found in a stable release.

Product notes

With 1Password you only ever need to memorize one password. All your other passwords and important information are protected by your Account Password, which only you know.

1Password is available for [https://1password.com/sign-up/](individuals, families, and teams.) Take a https://1password.com/tour/, learn about 1Password https://1password.com/security/, or browse [https://support.1password.com/](1Password Support.)