| [ Web Proxy ] |
| Viewing: https://stripe.com/it-si/docs/security/stripe | [Back] [Original] |
Our users trust Stripe with their sensitive data and rely on us to be good custodians of their customers data as well. As a payments infrastructure company, our security posture continually evolves to meet the rigorous standards of the global financial industry.
Stripe uses best-in-class security practices to maintain a high level of security.
A PCI-certified auditor evaluated Stripe and certified us to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry. This audit includes both Stripes Card Data Vault (CDV) and the secure software development of our integration code.
We provide our users with features to automate some aspects of PCI compliance.
Stripes systems, processes, and controls are regularly audited as part of our SOC 1 and SOC 2 compliance programs. SOC 1 and SOC 2 Type II reports are produced annually and can be provided upon request.
The Auditing Standards Board of the American Institute of Certified Public Accountants (AICPA) Trust Service Criteria (TSC) developed the SOC 3 report. Stripes SOC 3 is a public report of internal controls over security, availability, and confidentiality. View our recent SOC 3 report.
Stripe Terminal is certified to the EMVCo Level 1 and 2 standards of EMV Specifications for card and terminal security and interoperability. Terminal is also certified to the PCI Payment Application Data Security Standard (PA-DSS), the global security standard that aims to prevent payment applications developed for third parties from storing prohibited secure data.
Stripes suite of information security policies and their overarching design are aligned with the NIST Cybersecurity Framework. Our security practices meet the standards of our enterprise customers who must provide secure products like on-demand cloud computing and storage platforms (for example, DigitalOcean and Slack).
The Stripe privacy practices comply with CBPR and PRP systems as evidenced by the CBPR and PRP certifications Stripe has obtained. See the status of our CBPR and PRP certifications. Stripe also complies with the US Data Privacy Framework (EU-US DPF), the UK Extension to the EU-US DPF, and the Swiss-US Data Privacy Framework as set forth by the US Department of Commerce. See our certifications.
We continuously implement evolving privacy and data protection processes, procedures, and best practices under all applicable privacy and data protection regimes. For more information, see the following Stripe resources:
Security is one of Stripes guiding principles for all our product design and infrastructure decisions. We offer a range of features to help our users better protect their Stripe data.
The Stripe Dashboard supports several forms of multi-factor authentication (MFA) including passkeys, hardware security keys, time-based one-time password algorithm (TOTP), and SMS. We recommend passkeys or hardware security keys because theyre resistant to phishing. SMS-based MFA is vulnerable to SIM-swapping and interception, so use it only as a last resort. We also support single sign-on through Security Assertion Markup Language (SAML) 2.0, allowing you to mandate sign-in requirements, configure access control, and instantly onboard team members through just-in-time (JIT) account provisioning. If you use SSO with SCIM, you can enforce authentication policies centrally through your identity provider.
You must authenticate user support requests by sending them from the Dashboard after login, or by verifying account access before we offer a support response. By requiring authentication, we minimize the risk of providing any information to non-authorized people.
From the Dashboard, you can assign different detailed roles to enable least-privilege access for your employees, and create restricted API keys to reduce the security and reliability risk of API key exposure. You can also configure access policies for API keys to prevent use from unauthorized locations.
You can also view audit logs of important account changes and activity in your security history. These audit logs contain records of sensitive account activity, such as logging in or changing bank account information. We monitor logins and note:
Users can export historical information from the logs. For time-sensitive activities, specifically logins from unknown IPs and devices, Stripe sends automatic email notifications to the user, so they dont need to manually review the logs.
We mandate the use of HTTPS for all services using TLS (SSL), including our public website and the Dashboard. 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 make sure that browsers interact with Stripe only over HTTPS. Stripe is also on the HSTS preloaded lists for all modern major browsers. Our systems automatically block requests made using older, less secure versions of TLS, requiring use of at least TLS 1.2.
All Stripe internal server-to-server communication is encrypted using mutual transport layer security (mTLS). Stripe has dedicated PGP keys for you to encrypt email communications with Stripe, or verify signed messages you receive from us.
The stripe.com domain, including the Dashboard and API subdomains, are on the top domains list for Chrome, providing extra protection against homoglyph attacks. This makes it harder to create fake pages that look like stripe.com in Chrome (for example, strpe.com), which renders as punycode (xnstrpe-1sa.com), in turn making it harder for Stripe credentials to be phished.
We proactively scan the internet for our merchants API keys. If we find a compromised key, we take appropriate action, advising the user to roll their API key. We use the GitHub Token Scanner to alert us when a users API keys have been leaked on GitHub. If we find external phishing pages that might catch our users, we work proactively with our vendors to take those down and report them to Google Safe Browsing.
Our security teams test our infrastructure regularly by scanning for vulnerabilities and conducting penetration tests and red team exercises. We hire industry-leading security companies to perform third-party scans of our systems, and we immediately address their findings. Our servers are frequently and automatically replaced to maintain server health and discard stale connections or resources. Server operating systems are upgraded well in advance of their security end of life (EOL) date.
Stripe encrypts sensitive data both in transit and at rest. The Stripe infrastructure for storing, decrypting, and transmitting primary account numbers (PANs), such as credit card numbers, runs in a separate hosting infrastructure and doesnt share any credentials with the rest of our services. A dedicated team manages our CDV in an isolated Amazon Web Services (AWS) environment thats separate from the rest of the Stripe infrastructure. Access to this separate environment is restricted to a small number of specially trained engineers and access is reviewed quarterly.
All card numbers are encrypted at rest with AES-256. Decryption keys are stored on separate machines. We tokenize PANs internally, isolating raw numbers from the rest of our infrastructure. None of the Stripe internal servers and daemons can obtain plain text card numbers, but they can request that cards are sent to a service provider on a static allowlist. The Stripe infrastructure for storing, decrypting, and transmitting card numbers runs in a separate hosting environment, and doesnt share any credentials with primary Stripe services, including our API and website. We treat other sensitive data, such as bank account information, similarly to how we tokenize PANs.
Stripe takes a zero-trust approach to employee access management. Employees are authenticated with SSO, two-factor authentication (2FA) using a hardware-based token, and mTLS through a cryptographic certificate on Stripe-issued machines. After connecting to the network, sensitive internal systems and those outside the scope of the employees standard work require additional access permissions.
We monitor audit logs to detect abnormalities and watch for intrusions and suspicious activity, and also monitor changes to sensitive files in our code base. All of Stripes code goes through multiparty review and automated testing. Code changes are recorded in an immutable, tamper-evident log.
We constantly collect information about Stripe-issued laptops to monitor for malicious processes, connections to fraudulent domains, and intruder activity. We have a comprehensive process for allowlisting permitted software on employee laptops, preventing the installation of non-approved applications.
Our developers work with security experts early in a projects life cycle. As part of our Security Review process, security experts develop threat models and trust boundaries that help guide the implementation of the project. Developers use this same process to make changes to sensitive pieces of code.
We have a number of dedicated security teams that specialize in different areas of security, including infrastructure, operations, privacy, users, and applications. Security experts are available 24/7 through on-call rotations. Were focused on constantly raising the bar on best practices to minimize cybersecurity risks.
We require every Stripe employee to complete annual security education, and we provide secure software development training to Stripe engineers. We run internal phishing campaigns to test everyone at Stripe on recognizing phishing attempts and flagging them to the appropriate security team.
We have a formal process for granting access to systems and information, and we regularly review and automatically remove inactive access. Actions within the most sensitive areas of the infrastructure need a human review. To enable best practices for access control, our security experts build primitives to assist Stripe teams in implementing the principle of least privilege. To minimize our exposure, we have a data retention policy that reduces the data we keep while complying with regulatory and business requirements.
We maintain a vulnerability disclosure and reward (bug bounty) program that compensates independent security researchers who help us keep our users safe. By submitting a security bug or vulnerability to Stripe through HackerOne, you acknowledge that youve read and agreed to the program terms and conditions. Refer to our policy on HackerOne for more information about how to participate in our bug bounty program.
| Web Proxy Viewer | New URL | Original Page |