Stripe has been audited by a PCI-certified auditor and is certified to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry. To accomplish this, we use the best-in-class security tools and practices to maintain a high level of security at Stripe.
HTTPS and HSTS for secure connections
Stripe forces HTTPS for all services using TLS (SSL), including our public website and the Dashboard.
- Stripe.js is served only over TLS
- Stripe’s official libraries connect to Stripe’s servers over TLS and verify TLS certificates on each connection
We regularly audit the details of our implementation, including the certificates we serve, the certificate authorities we use, and the ciphers we support. We use HSTS to ensure that browsers interact with Stripe only over HTTPS. Stripe is also on the HSTS preloaded lists for both Google Chrome and Mozilla Firefox.
Encryption of sensitive data and communication
All card numbers are encrypted at rest with AES-256. Decryption keys are stored on separate machines. None of Stripe’s internal servers and daemons can obtain plaintext card numbers but can request that cards are sent to a service provider on a static allowlist. Stripe’s infrastructure for storing, decrypting, and transmitting card numbers runs in a separate hosting environment, and doesn’t share any credentials with Stripe’s primary services (API, website, etc.).
Vulnerability disclosure and reward program
Stripe maintains a private, invite-only bug bounty program, with the assistance of HackerOne. Invited researchers are eligible for a payment. While those who were not invited to the program may still submit a security bug or vulnerability to Stripe via HackerOne, such reports may not be eligible for a payment. To learn more about obtaining an invitation to the private bug bounty program, please see HackerOne’s website on invitations.
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.
Submit Vulnerability via HackerOne
You are about to submit a report to Stripe via HackerOne. Detailed and quality reporting is important to Stripe. You must include a working Proof of Concept.
Program Terms and Conditions
Your participation in our program is voluntary and subject to the below terms and conditions:
- 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.
- If you are performing research, please use your own accounts and do not interact with other users’ accounts or data.
- You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.
- Your testing must not violate any applicable laws or regulations.
- 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.
- 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.
- You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.
- You must be 18 years of age or older.
- 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.
- 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.
- 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.
- 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.
- 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.
Furthermore, Stripe does not consider the following to be eligible vulnerabilities:
- Account squatting by preventing users from registering with certain email addresses
- Attacks requiring MITM or physical access to a user’s device
- Best practice reports without a valid exploit (e.g. use of “weak” TLS ciphers)
- Clickjacking on pages with no sensitive actions
- Comma Separated Values (CSV) injection without demonstrating a vulnerability
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Denial of service
- Disclosure of server or software version numbers
- Hypothetical subdomain takeovers without supporting evidence
- Issues that require unlikely user interaction
- Missing best practices in Content Security Policy
- Missing best practices in SSL/TLS configuration
- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
- Missing HttpOnly or Secure flags on cookies
- Open redirect - unless an additional security impact can be demonstrated
- Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)
- Previously known vulnerable libraries without a working Proof-of-Concept
- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis
- Rate limiting or bruteforce issues on non-authentication endpoints
- Reports exploiting the behavior of, or vulnerabilities in, outdated browsers
- Reports of spam
- 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.)
- Social engineering
- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)
- Unconfirmed reports from automated vulnerability scanners
- User/merchant enumeration
- Vulnerabilities only affecting users of outdated or unpatched browsers (less than 2 stable versions behind the latest released stable version)
Valid reports for assets in the following domains are eligible for reward:
Valid reports of critical vulnerabilities for assets in the following domains are eligible for reward:
Out of Scope
Reports for assets in the following domains are not eligible for reward: