As an enterprise service provider, LogRocket understands that the security of the user data collected and stored by our customers is nothing less than critical. To deliver the peace of mind that our customers deserve, we believe in transparency regarding LogRocket's security standards and practices, which are constantly evolving to protect against security breaches and provide full confidentiality, data integrity, and availability.
Most importantly, you control exactly what data LogRocket records and stores. Please keep in mind as you review the security information below that the most effective way to minimize security exposure is to avoid storing unnecessarily sensitive data in the first place.
LogRocket builds on Google Cloud Platform’s compliance with leading standards for privacy and information security, including recurring re-examination by independent auditors. Our infrastructure provides robust software-level, hardware-level, and physical security. All data is encrypted in-flight and at rest. Administrative access to our servers and data requires login with Google two-step authentication, and employs Google's suspicious login detection and auditing.
We use Stripe for payment processing and do not store any credit card information. Stripe is a trusted, Level 1 PCI Service Provider. Learn more.
LogRocket provides clients with the ability to block recording and collection of any Personally Identifiable Information (PII) entered by keystroke, as well as any PII as defined by the customer contained within the webpage. LogRocket prevents the collection, saving, and display of PII via several tools, including:
Client-side keystroke block – By default, LogRocket never captures input elements of type
password. Customers can redact additional elements by using our APIs. LogRocket only captures form fields inputs, never raw keystrokes.
PII Labeling API – LogRocket has developed an API to identify and block any type of PII before it leaves the visitor’s browser. This tool enables our customers to easily identify PII fields to maintain the highest levels of data privacy.
Client-side HTML rewrite rules – When an HTML page is sent directly from the user’s browser to LogRocket's servers, any PII in the HTML (as identified by the customer) is removed using standard client-side expressions before it is sent across the network.
Client-side log sanitization – the LogRocket SDK has extensive controls for limiting data sent via logs. See Privacy for more information on programatic controls for removing PII data.
The LogRocket script is designed to minimize the impact on your application. See Performance for more information.
We force all network exchange between our SDK and servers to take place over TLS. Our certs are signed with SHA-256 ECDSA and use 256-bit ECC keys.
LogRocket supports SAML, SSO, and/or 2-factor authentication. Please reach out with specific authentication requirements, and we will happily work with you to develop a custom security plan.
All access to LogRocket REST API endpoints require an access key that can be regenerated on demand by customers.
Integrations with other applications are all opt-in and authenticate via OAuth or other applicable mechanisms required by the third party application. Integrations can be disabled at any time.
Exposed server endpoints are recurrently tested for vulnerabilities using multiple types of scanning software as well as manual testing. Request-handling code paths have frequent user re-authorization checks, payload size restrictions, rate limiting where appropriate, and other request verification techniques. All requests are logged and made searchable to operations staff.
Client code utilizes multiple techniques to ensure that using the LogRocket application is safe and that requests are authentic, including
- IFRAME sandboxing
- XSS and CSRF protection
- Signed and encrypted user auth cookies
- Remote invalidation of extant sessions upon password change/user deactivation
At any time, a LogRocket client can send an email to firstname.lastname@example.org and request that all their customer data be erased from all LogRocket systems. The request will be carried out by the LogRocket operations team within 24 hours and be followed by an email response confirming deletion of the data.
We use internal and third-party systems to monitor the confidentiality, integrity, and availability of our platform. If an incident occurs, a team of engineers is alerted immediately. And, if needed, we'll alert you (the customer) without delay.
We conduct routine vulnerability scans, penetration tests, and ensure our development efforts follow industry-standard guidelines/best practices.
LogRocket can, perhaps surprisingly, also produce substantial security enhancements for your own security practices.
While it is certainly not the reason that we developed LogRocket, we have heard from customers that LogRocket adds an additional layer of application security and fraud reproduction.
With LogRocket, you can explore, search and view any suspicious sessions in near real-time. Security engineers can replay sessions to quickly understand user behavior, instead of scouring through server log files.
Supporting your own customers may entail using shared administrative passwords or impersonation systems which allow employee to log-in as a customer. These systems expose your customer data to potential employee abuse, as they grant full read/write permissions to your application.
Instead of sharing passwords among your team, LogRocket provides a read-only view of customer usage data, enabling you to limit administrative access to data to only those that need it most.
Thus, LogRocket provides a way to better support your users, while also limiting the number of individuals with administrative privileges in your organization.
We follow the principle of least privilege in how we write software as well as the level of access employees are instructed to utilize in diagnosing and resolving problems in our software and in response to customer support requests.
We use Google account infrastructure to verify employee account identity and require physical security keys and/or two-factor authentication for all internal applications without exception. Access to administrative interfaces additionally enforce administrator permissions where applicable, and all administrative access is logged and auditable both in the form of traditional web server logs as well as via LogRocket itself to make it easy to find and review any administrative activities with full fidelity. For third-party SaaS providers, we utilize Google as an identity provider whenever possible to provide a single point of access control across all the apps that employees access as part of their job.
All changes to source code destined for production systems are subject to pre-commit code review by a qualified engineering peer that includes security, performance, and potential-for-abuse analysis.
Prior to updating production services, all contributors to the updated software version are required to approve that their changes are working as intended on staging servers.
LogRocket infrastructure utilizes multiple and layered techniques for increasingly reliable uptime, including the use of autoscaling, load balancing, task queues and rolling deployments. Due to the very large amount of data that LogRocket stores, we do not currently make point-in-time backups, although we do use highly redundant data stores and/or rapid recovery infrastructure, making unintentional loss of received data due to hardware failures very unlikely.
LogRocket does not allow third-party cookies in order to increase user privacy. In other words, LogRocket does not create a unique profile to track users across unrelated domains (domains that do not belong to the same customer).