Security

Learn how Bug Capture ensures your data’s privacy, security, and reliability.

A lot of Bug Capture’s users come from highly security-sensitive industries such as, banking, accounting, insurance, and even the public sector, which is why the topic of data handling is extremely important to us. In this document, you will find a summary of the principles and practices followed by our team to safeguard the privacy, security, and reliability of our services, in easy-to-understand language.

What kind of data does Bug Capture collect?

To help your team spend less time on reporting and fixing bugs, Bug Capture collects technical data generated while you interact with your product. This data includes general information such as your browser version, operating system, time of recording, console logs, URLs visited during the recording, network logs, and more.

When does Bug Capture collect this data?

Bug Capture only collects this data from the domains to which you grant it explicit access. The idea is that you only enable Bug Capture on the URLs of the product you are working on. Also, no data is uploaded to our servers until you explicitly press the upload button.

How is the data stored?

Our services are hosted in Google Cloud Platform data centers, and configured securely. All data centers are certified for information storage security (ISO 27001) and IT service management (ISO 20000). All of our services provide secure and encrypted Secure Sockets Layer (SSL) connections, so that data is encrypted in transit between our users’ computers and the servers. Likewise, communication between our services and third parties is always encrypted. User data on the servers is encrypted at rest at the storage level using the 256-bit Advanced Encryption Standard (AES-256), as recommended by the National Institute of Standards and Technology (NIST). Each encryption key is itself encrypted with a regularly rotated set of master keys.

Can I exclude certain types of data from being uploaded?

Yes, there are several ways to do so:

• Workspace level:
  
  • Disable all network logs: An Admin of the workspace can disable all network logs to be excluded from being uploaded to the server.
  • Redact sensitive information: We have automated methods to redact sensitive information, but you can also set up your own redactions using Regex patterns to exclude sensitive data from any session uploaded to the workspace. For more information, refer to the Redact information document.
• User level: In the extension settings, a user can granularly define which types of logs to record and which to exclude.

Who can view the recordings?

By default, only signed-in workspace members with Admin or Member roles can view the recordings. If required, however, Admins can allow workspace members to share the recordings outside the organization with Public links, i.e., anyone having the direct link to the recording can view it. Even for public links, we randomize all IDs and asset names with high entropy, ensuring that even session URLs cannot be guessed or accessed by unauthorized individuals with whom the recording was not shared. Furthermore, within the workspace, the recordings can be organized into folders. These folders can be either Private (only invited members of the workspace can view) or Public (anyone in the workspace can view). For more information, refer to the Folders document.

How do you keep the application code secure?

• Automated dependency scanning: We limit our use of third-party code where possible. We continuously scan our code for known security flaws using dependency scanning. You can verify the list of third party packages we use here.
• Content security policy and security related headers: Our applications use strict CSP headers, which ensure that only code commissioned by us is executed on clients. We also set restrictive HTTP headers to prevent our applications, for example, from being embedded by bad actors.

How does Bug Capture’s team protect the service?

Our team makes it a habit to follow best practices:

• Training and operational security: All employees receive security training during onboarding and at least once per year thereafter. Our comprehensive policies include, among other things, the encryption of all computers and the use of password managers for all business accounts. Business accounts are automatically scanned for breaches. We ensure the use of Multi-Factor Authentication (MFA) for tools we use to build Bug Capture. We also use a VPN to mitigate risks caused by potentially insecure networks.
• Limited access: We follow the need-to-know principle and the principle of least privilege. This means that we limit access to customer data to the smallest group of staff possible. Only two team members can access the production database, which is required to provide the service and ensure high uptime. We do not give employees access to more data than is required for them to fulfill their roles.
• Environment segregation: All product development and testing occurs in environments with separate databases and user pools. This ensures that product development does not impact customer data.
• Confidentiality: Employees are bound by additional contractual confidentiality clauses.

General questions on Bug Capture

This section contains some of the most frequently asked questions about Bug Capture to help you better understand how it works.

How does Bug Capture differ from error monitoring tools?

There are various services on the market that allow you to record technical logs and actions performed by end users on web applications. We believe that the approach of always-on recording live user interactions has several important privacy downsides:

• Users generally do not know that they are being recorded. Even though they can find out by checking the Terms of Service or Privacy Policy, most people do not read them and remain unaware.
• It is easy to forget to exclude certain fields (e.g., passwords, credit card details, etc.) from being recorded, which means that critical private information can be seen by people who should not have access to it.
  

These downsides were some of the reasons we decided to build Bug Capture and create mechanisms to prevent them from occurring in our product:

• Bug Capture is mostly used on pre-production environments, where 80% of the bugs are discovered, yet no live customer data is stored.
• Bug Capture does not upload anything before you explicitly choose to do so, and it allows you to review the data before uploading it.