Security

We're often asked about the security and safety of your data. In this page we'll describe some of the steps we take to prevent leakage of your intellectual property. If you have any further concerns, please feel free to reach out!

Keeping your Code safe

Screenshotbot does not need access to your code. It does not need access to any metadata in your Git repository. During the CI step, Screenshotbot creates a "commit graph": This is a commit graph of only the commit hashes, and for each commit hash its parent commit hashes. This is the only information we need about your code.

On GitHub and Azure DevOps, we require permission to update the build statuses on commits and Pull Requests. This permission does not grant us the ability to read or write code.

On BitBucket, GitLab and Phabricator, we only use the APIs to update build statuses, but the platforms don't provide granular permissions. So a simple configuration using these platforms might provide us access to read and write code, even though we don't use it. Our corresponding documention provides suggestions on how to limit the scope of the access to only certain repositories.

In every case, we provide audit logs of each time Screenshotbot makes any API call to your services. If you're still concerned, we can help you set up Screenshotbot to update build statuses via webhooks.

Keeping your Images safe

By default, all images uploaded to Screenshotbot are sent over an encrypted channel, and are stored on Screenshotbot's servers. In particular, we do not serve images over an external object storage such as S3.

This means that we can have tight controls over who can access your images.

Image URLs

Image URLs have encrypted information in order to access the image:

Anyone who is given this URL can access the image. (But we can override this if you wish!) This URL cannot be guessed, the only way to get access to this URL is to log in to your dashboard and copy the image URL for whichever image you are looking for.

CDN

By default, we might use CDNs to link to the images. In this situation the image might be cached on the CDN (we use CloudFront which is run by Amazon). But again, nobody can access the image unless they have the encrypted identifier. We can disable the CDN on request.

Stronger restrictions

The use of the CDN and publicly accessible image URLs are meant to protect us from Denial of Service attacks. However, we understand that some enterprise customers might want to restrict access to images further, perhaps for legal reasons, or just to reduce the chance of a leak by someone who has access to your account.

For enterprise customers, if you wish, we can ensure that images are only accessible to users who are logged in. In this setup, if somebody has access to the URL, they would not be able to access the image. We would not use a CDN if you choose to go this route (since using a CDN would prevent us from doing access checks).

Third-party Vendors

The only third-party vendors that hold our customers' data are data-center providers and CDN providers.

We use Linode (owned by Akamai) for compute and storage. We currently operate from their Newark DC. See their certifications here.

We use Amazon CloudFront as a CDN. We send emails via Amazon SES.