[{"id":3765188,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nSubmission severity is evaluated based on Stripe specific threat models, which factors in Stripe's internal usage of the application or domain in question.\n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"Unconfirmed Reports from Automated Vulnerability Scanners\",\"details\":\"Submitting a report from an automated scanner without reproducing the result and demonstrating a direct working exploit.\"}","{\"category\":\"LLM Prompt Injection or Leaks without Security Risk\",\"details\":\"LLM prompt injections or leaks without a clear and obvious security risk. Submissions must provide a working security exploit to be considered.\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}","{\"category\":\"Leaked User Credentials\",\"details\":\"Stripe accepts reports of but does not provide bounty for leaked user credentials (for example from password dumps, GitHub scraping, etc).\"}"],"timestamp":"2025-10-27T16:47:25.723Z"},{"id":3759859,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"Unconfirmed Reports from Automated Vulnerability Scanners\",\"details\":\"Submitting a report from an automated scanner without reproducing the result and demonstrating a direct working exploit.\"}","{\"category\":\"LLM Prompt Injection or Leaks without Security Risk\",\"details\":\"LLM prompt injections or leaks without a clear and obvious security risk. Submissions must provide a working security exploit to be considered.\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}","{\"category\":\"Leaked User Credentials\",\"details\":\"Stripe accepts reports of but does not provide bounty for leaked user credentials (for example from password dumps, GitHub scraping, etc).\"}"],"timestamp":"2025-07-23T16:01:01.505Z"},{"id":3750753,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"Unconfirmed Reports from Automated Vulnerability Scanners\",\"details\":\"Submitting a report from an automated scanner without reproducing the result and demonstrating a direct working exploit.\"}","{\"category\":\"LLM Prompt Injection or Leaks without Security Risk\",\"details\":\"LLM prompt injections or leaks without a clear and obvious security risk. Submissions must provide a working security exploit to be considered.\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2025-02-24T17:30:30.630Z"},{"id":3748216,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"Unconfirmed Reports from Automated Vulnerability Scanners\",\"details\":\"Submitting a report from an automated scanner without reproducing the result and demonstrating a direct working exploit.\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2025-01-16T15:05:20.070Z"},{"id":3747661,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the permission is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}","{\"category\":\"Unconfirmed Reports from Automated Vulnerability Scanners\",\"details\":\"Submitting a report from an automated scanner without reproducing the result and demonstrating a direct working exploit.\"}"],"timestamp":"2025-01-08T17:52:36.176Z"},{"id":3747653,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the permission is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2025-01-08T17:35:09.785Z"},{"id":3747643,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n  - Stripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}","{\"category\":\"RBAC / Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the permission is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2025-01-08T15:59:56.472Z"},{"id":3746619,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n  - Stripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}","{\"category\":\"Self-XSS, Self-Exploitation, and Unlikely User Interactions\",\"details\":\"Issues that rely on unlikely user interactions or require the user to intentionally configure their environment in a way that compromises their own security (e.g., modifying configuration files, scripts, or debugging setups that are not standard or recommended practices).\"}"],"timestamp":"2024-12-15T13:22:36.923Z"},{"id":3746004,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n  - Stripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a [HackerOne email address](https://docs.hackerone.com/en/articles/8404308-hacker-email-alias) (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Self-XSS or Unlikely User Interactions\",\"details\":\"Issues that are premised on unlikely user interaction or self-xss by the user.\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2024-12-05T20:25:00.250Z"},{"id":3746003,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n  - Stripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus.\n\nAs a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Self-XSS or Unlikely User Interactions\",\"details\":\"Issues that are premised on unlikely user interaction or self-xss by the user.\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2024-12-05T20:24:01.698Z"},{"id":3746002,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- We **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules.\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@wearehackerone.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Self-XSS or Unlikely User Interactions\",\"details\":\"Issues that are premised on unlikely user interaction or self-xss by the user.\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2024-12-05T20:06:27.127Z"},{"id":3745992,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- Please note that we **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Self-XSS or Unlikely User Interactions\",\"details\":\"Issues that are premised on unlikely user interaction or self-xss by the user.\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2024-12-05T19:22:51.361Z"},{"id":3745990,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Other Notes on Submission Eligibility\n- Please note that we **accept and reward** submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy, or reach out to bugbounty@stripe.com with any questions.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program scope to bugbounty AT stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Account Squatting\",\"details\":\"Account squatting preventing users from registering with certain email addresses\"}","{\"category\":\"Physical Access / Man in the Middle\",\"details\":\"Attacks requiring MITM or physical access to a user's device\"}","{\"category\":\"CWEs / Missing Best Practices without Exploits\",\"details\":\"Perceived security weaknesses without concrete evidence of an exploit or the ability to compromise a user. Including CSP, SSL/TLS (weak ciphers), email configuration (invalid SPF/DKIM/DMARC), cookie configuration (HttpOnly/Secure flags), rate limits, security headers.\"}","{\"category\":\"Non-sensitive Clickjacking\",\"details\":\"Clickjacking on pages with no sensitive actions\"}","{\"category\":\"CSV Injection without a Vulnerability\",\"details\":\"Comma Separated Values (CSV) injection without demonstrating a vulnerability\"}","{\"category\":\"Content Spoofing / Text Injection without an Attack Vector\",\"details\":\"Content spoofing and text injection issues without showing an attack vector or without being able to modify HTML/CSS\"}","{\"category\":\"Non-sensitive CSRF\",\"details\":\"Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\"}","{\"category\":\"Denial of Service\",\"details\":\"Denial of service attacks\"}","{\"category\":\"Software Version or Descriptive Errors\",\"details\":\"Disclosure software version, server version, banner identification issues, descriptive error messages or headers (e.g. stack traces, application or server errors)\"}","{\"category\":\"Hypothetical Subdomain Takeovers\",\"details\":\"Hypothetical subdomain takeovers without supporting evidence\"}","{\"category\":\"Self-XSS or Unlikely User Interactions\",\"details\":\"Issues that are premised on unlikely user interaction or self-xss by the user.\"}","{\"category\":\"Open Redirects\",\"details\":\"Unless an additional security impact can be demonstrated\"}","{\"category\":\"Vulnerable Libraries without Demonstrated Exploits\",\"details\":\"Previously known vulnerable libraries without a working proof of concept\"}","{\"category\":\"New Public Zero-Day Vulnerabilities\",\"details\":\"Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\"}","{\"category\":\"Rate limiting / Brute Force on Non-authentication Endpoints\",\"details\":\"Rate limiting or brute force issues on non-authentication endpoints\"}","{\"category\":\"Outdated / EOL Browser Exploits\",\"details\":\"Reports exploiting the behavior of or vulnerabilities in outdated or end of life browsers. Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version).\"}","{\"category\":\"Spam\",\"details\":\"Reports of spam\"}","{\"category\":\"Social Engineering including Phishing\",\"details\":\"Reports of exploits involving social engineering against Stripe employees, contractors, users, etc. This includes phishing and tabnabbing.\"}","{\"category\":\"Web Crawler Results\",\"details\":\"URLs indexed by web crawlers or archivers. For example, receipt URLs in Wayback Machine\"}","{\"category\":\"Account Management Session Invalidation\",\"details\":\"Session invalidation and other security enhancements in account management when credentials are known (e.g., password reset links that do not expire immediately or adding a new multi-factor authentication does not invalidate existing sessions).\"}","{\"category\":\"Role Permissions without Security Risk\",\"details\":\"User role permissions without a clear and obvious security risk or if the role is not explicitly prohibited in our documentation. Role functionality through the API but not the Dashboard will not be considered a permission issue. Role documentation: https://stripe.com/docs/account/teams/roles\"}"],"timestamp":"2024-12-05T19:20:50.818Z"},{"id":3713603,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules\n- We will not consider reports concerning user role permissions for reward unless the report demonstrates a clear and obvious security risk or that a role can do something that is explicitly prohibited in our documentation. Availability of functionality to a role through the API but not the Dashboard UI will not be considered as a permission issue. Stripe Dashboard user role documentation can be found here: https://stripe.com/docs/account/teams/roles\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy, or reach out to bugbounty@stripe.com with any questions.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program scope to bugbounty AT stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-04T22:10:59.362Z"},{"id":3689027,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass\n  - If submitting an XSS vulnerability without a CSP bypass, please demonstrate impact by manually disabling the CSP in your web browser. This can be done via browser extensions or Burp/proxy match-and-replace rules\n- We will not consider reports concerning user role permissions for reward unless the report demonstrates a clear and obvious security risk or that a role can do something that is explicitly prohibited in our documentation. Availability of functionality to a role through the API but not the Dashboard UI will not be considered as a permission issue. Stripe Dashboard user role documentation can be found here: https://stripe.com/docs/account/teams/roles\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge. Note that, due to the complexity of account security, regional and feature limitations, and other regulatory mechanisms, a perceived bypass in post-authentication challenges may not exist in actuality\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy, or reach out to bugbounty@stripe.com with any questions.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-07T17:29:01.054Z"},{"id":3686756,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n- We will not consider reports concerning user role permissions for reward unless the report demonstrates a clear and obvious security risk or that a role can do something that is explicitly prohibited in our documentation. Availability of functionality to a role through the API but not the Dashboard UI will not be considered as a permission issue. Stripe Dashboard user role documentation can be found here: https://stripe.com/docs/account/teams/roles\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\n\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy, or reach out to bugbounty@stripe.com with any questions.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-01T22:11:15.640Z"},{"id":3686753,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n- We will not consider reports concerning user role permissions for reward unless the report demonstrates a clear and obvious security risk or that a role can do something that is explicitly prohibited in our documentation. Availability of functionality to a role through the API but not the Dashboard UI will not be considered as a permission issue. Stripe Dashboard user role documentation can be found here: https://stripe.com/docs/account/teams/roles\n- Beginning in May 2023, Stripe is offering an additional $500 bonus for vulnerabilities that could be exploited to enable fraudulent activity on or against Stripe, such as:\n  - Mass enumeration of valid Stripe users or credentials using Stripe’s infrastructure\n  - Performing any actions which normally require a post-authentication challenge (e.g., re-entering your password, OTP, etc.) without needing to complete the challenge\n  - Unauthorized movement of funds that could result in monetary loss for Stripe or its users\nStripe, in its sole discretion, determines whether a vulnerability could be exploited to enable fraudulent activity and qualifies for the bonus. As a reminder,  you must use your own accounts to conduct any research and not interact with other Stripe users’ accounts. For further information, please refer to the “Rules of Engagement” section of our policy, or reach out to bugbounty@stripe.com with any questions.\n\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-01T22:03:02.390Z"},{"id":3685857,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n- We will not consider reports concerning Stripe Dashboard user role permissions for reward unless the report demonstrates a clear and obvious security risk or that a role can do something that is explicitly prohibited in our documentation. Availability of functionality to a role through the API but not the Dashboard UI will not be considered as a permission issue. Stripe Dashboard user role documentation can be found here: https://stripe.com/docs/account/teams/roles\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-05T21:13:14.386Z"},{"id":3684981,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- URLs indexed by web crawlers or archivers (such as receipt URLs in Wayback)\n- Unconfirmed reports from automated vulnerability scanners\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-03-17T18:49:41.124Z"},{"id":3679080,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name. In addition, you must inject an ‘X-Bug-Bounty: username’ header, where possible.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-26T19:06:39.628Z"},{"id":3679077,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms'') governs your participation in the Stripe Bug Bounty Program (\"Program\"). These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\"). By performing vulnerability research against Stripe’s infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\n- Participants must be at least 18 years old.  \n- Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list. \n \n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n- Your submission must include a working Proof of Concept to be considered for a reward.\n- Avoid harm to others’ data and privacy. Specifically: \n  - If you encounter any personal data or sensitive information in the course of your research, **stop and notify our team immediately so we can investigate**. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others’ data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.\n  - If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is **absolutely necessary** to achieve those purposes (i.e., identification and demonstration of a vulnerability that could allow unauthorized access to personal data or sensitive information). For example, if you are injecting code into Stripe’s environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database. \n  - If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.        \n- Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.\nDo not not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe’s systems and data (e.g., modifying or deleting data). If you notice service degradation or interruption, stop your research and notify us immediately. \n- Do not incur loss of funds that are not your own.\n- If you are performing research, use your own accounts to do so. Do not interact with other Stripe users’ accounts. See the “Creating Accounts for Vulnerability Research” section below for more detail.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.\n- We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.\n- Your research must not violate any applicable laws or regulations.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nAs explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Ineligible Vulnerabilities\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other Notes on Submission Eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Creating Accounts for Vulnerability Research\nYou must create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity. When opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n \n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe’s prior written approval. There are no exceptions.\n\n##Researcher Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program. \n\n##Contact\nFeel free to submit any comments or questions about our program to bugbounty@stripe.com.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-26T18:57:00.119Z"},{"id":3676474,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms\") governs your participation in the Stripe Bug Bounty Program (the \"Program\").  These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\").  By submitting any vulnerabilities to Stripe or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\nParticipants must be at least 18 years old.  \nStripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n\nYou are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List.  By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n\nThose who meet the eligibility requirements above and discover a potential security finding within Stripe products or services can submit a report to the Program.\n\n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n\n- You must include a working Proof of Concept.\n- You must not threaten or try to extort Stripe. \n- You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.\n- You must not access non-public information without authorization.\n- You must not degrade, interrupt, or deny services to our users.\n- You must not incur loss of funds that are not your own.\n- If you are performing research, you must use your own accounts and not interact with other users’ accounts or data. \n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so that Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion.\n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid.  All other reports for a given issue will not be eligible for a reward under our program.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility. The review time will vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nStripe retains sole discretion in determining which submissions are qualified. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n\n##Creating Accounts for Vulnerability Research\n\n**You must** create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity.  \n\nWhen opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n\n##Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. \n\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other notes on submission eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third parties without Stripe’s prior written approval. There are no exceptions.\n\n\n##Personal Data\nYou must never attempt to access personal data that belongs to others, whether by exploiting a vulnerability or not. If, during your testing, you interacted with or obtained access to personal data of others, you must:\n- Stop your testing immediately and cease any activity that involves the data or the vulnerability;\n- Do not save, copy, store, transfer, disclose, or otherwise retain the data; and\n- Alert Stripe immediately and support our investigation and mitigation efforts.\n\nFailure to comply with this section will immediately disqualify any report from bounty award eligibility.\n\n##Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time.  Participating in the Program after the changes become effective means you agree to the new Terms.  If you don't agree to the new Terms, you must not participate in the Program.  \n\nIf you wish to opt out of the Program, please contact us at security@stripe.com. \n\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-23T16:22:45.229Z"},{"id":3676472,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms\") governs your participation in the Stripe Bug Bounty Program (the \"Program\").  These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\").  By submitting any vulnerabilities to Stripe or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\nParticipants must be at least 18 years old.  \nStripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n\nYou are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List.  By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n\nThose who meet the eligibility requirements above and discover a potential security finding within Stripe products or services can submit a report to the Program.\n\n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n\n- You must include a working Proof of Concept.\n- You must not threaten or try to extort Stripe. \n- You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.\n- You must not access non-public information without authorization.\n- You must not degrade, interrupt, or deny services to our users.\n- You must not incur loss of funds that are not your own.\n- If you are performing research, you must use your own accounts and not interact with other users’ accounts or data. \n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so that Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion.\n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid.  All other reports for a given issue will not be eligible for a reward under our program.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility. The review time will vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nStripe retains sole discretion in determining which submissions are qualified. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\n##Creating Accounts for Vulnerability Research\n\n**You must** create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity.  \n\nWhen opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n\n##Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. \n\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other notes on submission eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third parties without Stripe’s prior written approval. There are no exceptions.\n\n\n##Personal Data\nYou must never attempt to access personal data that belongs to others, whether by exploiting a vulnerability or not. If, during your testing, you interacted with or obtained access to personal data of others, you must:\n- Stop your testing immediately and cease any activity that involves the data or the vulnerability;\n- Do not save, copy, store, transfer, disclose, or otherwise retain the data; and\n- Alert Stripe immediately and support our investigation and mitigation efforts.\n\nFailure to comply with this section will immediately disqualify any report from bounty award eligibility.\n\n##Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time.  Participating in the Program after the changes become effective means you agree to the new Terms.  If you don't agree to the new Terms, you must not participate in the Program.  \n\nIf you wish to opt out of the Program, please contact us at security@stripe.com. \n\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-23T16:16:39.915Z"},{"id":3676471,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms\") governs your participation in the Stripe Bug Bounty Program (the \"Program\").  These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\").  By submitting any vulnerabilities to Stripe or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\nParticipants must be at least 18 years old.  \nStripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n\nYou are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List.  By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n\nThose who meet the eligibility requirements above and discover a potential security finding within Stripe products or services can submit a report to the Program.\n\n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n\n- You must include a working Proof of Concept.\n- You must not threaten or try to extort Stripe. \n- You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.\n- You must not access non-public information without authorization.\n- You must not degrade, interrupt, or deny services to our users.\n- You must not incur loss of funds that are not your own.\n- If you are performing research, you must use your own accounts and not interact with other users’ accounts or data. \n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so that Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion.\n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid.  All other reports for a given issue will not be eligible for a reward under our program.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility. The review time will vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nStripe retains sole discretion in determining which submissions are qualified. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\n##Creating Accounts for Vulnerability Research\n\n**You must** create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity.  \n\nWhen opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n\n##Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. \n\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other notes on submission eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third parties without Stripe’s prior written approval. There are no exceptions.\n\n\n##Personal Data\nYou must never attempt to access personal data that belongs to others, whether by exploiting a vulnerability or not. If, during your testing, you interacted with or obtained access to personal data of others, you must:\n- Stop your testing immediately and cease any activity that involves the data or the vulnerability;\n- Do not save, copy, store, transfer, disclose, or otherwise retain the data; and\n- Alert Stripe immediately and support our investigation and mitigation efforts.\n\nFailure to comply with this section will immediately disqualify any report from bounty award eligibility.\n\n##Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time.  Participating in the Program after the changes become effective means you agree to the new Terms.  If you don't agree to the new Terms, you must not participate in the Program.  \n\nIf you wish to opt out of the Program, please contact us at security@stripe.com. \n\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-23T16:15:32.233Z"},{"id":3668156,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms\") governs your participation in the Stripe Bug Bounty Program (the \"Program\").  These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\").  By submitting any vulnerabilities to Stripe or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\nParticipants must be at least 18 years old.  \nStripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n\nYou are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List.  By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n\nThose who meet the eligibility requirements above and discover a potential security finding within Stripe products or services can submit a report to the Program.\n\n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n\n- You must include a working Proof of Concept.\n- You must not threaten or try to extort Stripe. \n- You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.\n- You must not access non-public information without authorization.\n- You must not degrade, interrupt, or deny services to our users.\n- You must not incur loss of funds that are not your own.\n- If you are performing research, you must use your own accounts and not interact with other users’ accounts or data. \n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so that Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion.\n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid.  All other reports for a given issue will not be eligible for a reward under our program.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility. The review time will vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nStripe retains sole discretion in determining which submissions are qualified. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.\n\n##Creating Accounts for Vulnerability Research\n\n**You must** create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity.  \n\nWhen opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n\n##Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. \n\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Other notes on submission eligibility\n- Please note that we do accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.\n\n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third parties without Stripe’s prior written approval. There are no exceptions.\n\n##Personal Data\nYou must never attempt to access personal data that belongs to others, whether by exploiting a vulnerability or not. If, during your testing, you interacted with or obtained access to personal data of others, you must:\n- Stop your testing immediately and cease any activity that involves the data or the vulnerability;\n- Do not save, copy, store, transfer, disclose, or otherwise retain the data; and\n- Alert Stripe immediately and support our investigation and mitigation efforts.\n\nFailure to comply with this section will immediately disqualify any report from bounty award eligibility.\n\n##Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time.  Participating in the Program after the changes become effective means you agree to the new Terms.  If you don't agree to the new Terms, you must not participate in the Program.  \n\nIf you wish to opt out of the Program, please contact us at security@stripe.com. \n\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-03-16T17:53:32.211Z"},{"id":3667735,"new_policy":"The Stripe Bug Bounty Program Terms and Conditions (\"Terms\") governs your participation in the Stripe Bug Bounty Program (the \"Program\").  These Terms are between you and Stripe (\"Stripe,\" \"us,\" or \"we\").  By submitting any vulnerabilities to Stripe or otherwise participating in the Program in any manner, you accept these Terms.\n\n##Program Eligibility\nParticipants must be at least 18 years old.  \nStripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.\n\nYou are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including, but not limited to, Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons List or Entity List.  By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n\nThose who meet the eligibility requirements above and discover a potential security finding within Stripe products or services can submit a report to the Program.\n\n##Rules of Engagement\nYour participation in our program is voluntary and subject to the following:\n\n- You must include a working Proof of Concept.\n- You must not threaten or try to extort Stripe. \n- You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.\n- You must not access non-public information without authorization.\n- You must not degrade, interrupt, or deny services to our users.\n- You must not incur loss of funds that are not your own.\n- If you are performing research, you must use your own accounts and not interact with other users’ accounts or data. \n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.\n- By reporting a vulnerability, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so that Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion.\n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid.  All other reports for a given issue will not be eligible for a reward under our program.\n\n##Submission Review Process\nAfter a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility. The review time will vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive. \n\nStripe retains sole discretion in determining which submissions are qualified. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report.\n\n##Creating Accounts for Vulnerability Research\n\n**You must** create your own account using a HackerOne email address (username@WeAreHackerOne.com) to help us track security research activity.  \n\nWhen opening your own merchant account, please add “bug-bounty” to the end of the merchant name.\n\n##Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. \n\nBelow are some examples of issues that are out of scope for the Stripe Bug Bounty Program:\n\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g., use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that are premised on unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n\n##Disclosure\nBy participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third parties without Stripe’s prior written approval. There are no exceptions.\n\n##Personal Data\nYou must never attempt to access personal data that belongs to others, whether by exploiting a vulnerability or not. If, during your testing, you interacted with or obtained access to personal data of others, you must:\n- Stop your testing immediately and cease any activity that involves the data or the vulnerability;\n- Do not save, copy, store, transfer, disclose, or otherwise retain the data; and\n- Alert Stripe immediately and support our investigation and mitigation efforts.\n\nFailure to comply with this section will immediately disqualify any report from bounty award eligibility.\n\n##Privacy\nTo protect your privacy, we will not, unless served with legal process or to address a violation of this policy:\n- Share your personally identifiable information with third parties\n- Share your research without your permission\n- Share your participation without your permission\n\n##Accountability \nStripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.   \n\n##Changes to the Terms\nWe may change the Terms at any time.  Participating in the Program after the changes become effective means you agree to the new Terms.  If you don't agree to the new Terms, you must not participate in the Program.  \n\nIf you wish to opt out of the Program, please contact us at security@stripe.com. \n\n\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-03-07T21:16:52.046Z"},{"id":3655568,"new_policy":"By submitting a security bug or vulnerability to Stripe via HackerOne, you acknowledge that you have read and agreed to the Program Terms and Conditions set forth below.  By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval.\n\n# Terms and Conditions\n \nDetailed and quality reporting is important to Stripe. You must include a working Proof of Concept.\n \nYour participation in our program is voluntary and subject to the below terms and conditions: \n- You need to show that you could exploit a vulnerability, but you must not actually exploit it. You must not: access, modify, copy, download, delete, compromise or otherwise misuse others’ data; access non-public information without authorization; degrade, interrupt or deny services to our users; and/or incur loss of funds that are not your own. \n- If you are performing research, please use your own accounts and do not interact with other users’ accounts or data. When creating your own accounts, please use your username@WeAreHackerOne.com email address. Also, when opening your own merchant account accounts, please add “-bug-bounty” to the end of the merchant name.\n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including but not limited to Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Person’s List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n- By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval. \n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- You must be 18 years of age or older.  \n- You must not be employed by Stripe or any of its affiliates. You must also not be an immediate family member of someone employed by Stripe or any of its affiliates.\n- By reporting a bug, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.  \n- By reporting a bug, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion, and we may cancel or modify the program at any time. \n- Only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue will be marked as valid. All other reports for a given issue will not be eligible for reward under our program.\n\n# Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g. use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that require unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-26T17:29:10.616Z"},{"id":3654400,"new_policy":"By submitting a security bug or vulnerability to Stripe via HackerOne, you acknowledge that you have read and agreed to the Program Terms and Conditions set forth below.  By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval.\n\n# Terms and Conditions\n \nDetailed and quality reporting is important to Stripe. You must include a working Proof of Concept.\n \nYour participation in our program is voluntary and subject to the below terms and conditions: \n- You need to show that you could exploit a vulnerability, but you must not actually exploit it. You must not: access, modify, copy, download, delete, compromise or otherwise misuse others’ data; access non-public information without authorization; degrade, interrupt or deny services to our users; and/or incur loss of funds that are not your own. \n- If you are performing research, please use your own accounts and do not interact with other users’ accounts or data. When creating your own accounts, please use your username@WeAreHackerOne.com email address. Also, when opening your own merchant account accounts, please add “-bug-bounty” to the end of the merchant name.\n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including but not limited to Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Person’s List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n- By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval. \n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- You must be 18 years of age or older.  \n- You must not be employed by Stripe or any of its affiliates. You must also not be an immediate family member of someone employed by Stripe or any of its affiliates.\n- By reporting a bug, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.  \n- By reporting a bug, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion, and we may cancel or modify the program at any time. \n- Only the first, responsibly-disclosed submission of a vulnerability instance will be marked as valid, any subsequent reports will not be eligible for our program. \n\n# Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Account squatting by preventing users from registering with certain email addresses\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g. use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that require unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-08T15:13:47.389Z"},{"id":3654306,"new_policy":"By submitting a security bug or vulnerability to Stripe via HackerOne, you acknowledge that you have read and agreed to the Program Terms and Conditions set forth below.  By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval.\n\n# Terms and Conditions\n \nDetailed and quality reporting is important to Stripe. You must include a working Proof of Concept.\n \nYour participation in our program is voluntary and subject to the below terms and conditions: \n- You need to show that you could exploit a vulnerability, but you must not actually exploit it. You must not: access, modify, copy, download, delete, compromise or otherwise misuse others’ data; access non-public information without authorization; degrade, interrupt or deny services to our users; and/or incur loss of funds that are not your own. \n- If you are performing research, please use your own accounts and do not interact with other users’ accounts or data. When creating your own accounts, please use your username@WeAreHackerOne.com email address. Also, when opening your own merchant account accounts, please add “-bug-bounty” to the end of the merchant name.\n- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.\n- Your testing must not violate any applicable laws or regulations.\n- You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including but not limited to Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Person’s List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list.\n- By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval. \n- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.\n- You must be 18 years of age or older.  \n- You must not be employed by Stripe or any of its affiliates. You must also not be an immediate family member of someone employed by Stripe or any of its affiliates.\n- By reporting a bug, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.  \n- By reporting a bug, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so Stripe can perform compliance checks.\n- Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion, and we may cancel or modify the program at any time. \n- Only the first, responsibly-disclosed submission of a vulnerability instance will be marked as valid, any subsequent reports will not be eligible for our program. \n\n# Ineligible Vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Attacks requiring MITM or physical access to a user's device\n- Best practice reports without a valid exploit (e.g. use of \"weak\" TLS ciphers)\n- Clickjacking on pages with no sensitive actions\n- Comma Separated Values (CSV) injection without demonstrating a vulnerability\n- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n- Denial of service\n- Disclosure of server or software version numbers\n- Hypothetical subdomain takeovers without supporting evidence\n- Issues that require unlikely user interaction\n- Missing best practices in Content Security Policy\n- Missing best practices in SSL/TLS configuration\n- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n- Missing HttpOnly or Secure flags on cookies\n- Open redirect - unless an additional security impact can be demonstrated\n- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)\n- Previously known vulnerable libraries without a working Proof-of-Concept\n- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis\n- Rate limiting or bruteforce issues on non-authentication endpoints\n- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers\n- Reports of spam\n- Self-XSS\n- Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)\n- Social engineering\n- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)\n- Tabnabbing\n- Unconfirmed reports from automated vulnerability scanners\n- User/merchant enumeration\n- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-06T17:41:22.185Z"}]