Security FAQ
GitBook is a tech startup, incorporated in the U.S as
GitBook Inc , with a French subsidiary GitBook SASWe are hosted on Google Cloud, which is backed by the same infrastructure and security that Google uses for its own services.
Customer data is stored in U.S. data centers. Some data (HTML pages & assets) may be cached in other geographies by our CDN. Access to private content through our CDN is always validated through our application servers using a complex permissions system.
Google follows or even leads most of the industry's best-practices and is compliant with most major security standards and certifications.
Yes, all customer data is encrypted at rest and in-transit:
- In transit, we use HTTPS to encrypt all traffic served to end-users.
By default, all customer data, unless explicitly public, can only be accessed by authenticated users with valid permissions.
You can control and restrict access through our Teams feature, allowing you to invite external members to join your organization and collaborate, whilst restricting their access to a chosen subset of your projects.
The only required piece of information to sign up and start using GitBook is an email address.
Depending on the risk evaluation performed using the Clearbit Risk API, a phone number may be necessary for new users. The risk evaluation is based on a combination of the provided email address and the visitor's IP address.
When subscribing to a plan, the user will be asked for credit card informations. These informations never reach our servers and are processed by Stripe only.
Stripe gives us access to the expiration date, the brand and the last 4 digits of the credit card only, which are stored in our database for convenience. The user can opt-in to provide us with a billing address, which is also stored in our database. As for the credit card partial informations, the billing address is private and only accessible by the GitBook organization's and the application's administrators.
GitBook leverages the following 3rd-party services and APIs:
Since these services provide the highest standards and are regularly externally audited, GitBook does not audit them by its own means.
Each user on GitBook is assigned an unique identifier when her/his account is created. When creating or joining a GitBook organization, each user is then assigned a role: reader, writer or admin. This role is then used to derivate a set of permissions for each member of the organization.
These permissions are then applied directly at the database level, thanks to the Firebase Realtime Database security rules. For each request that reaches our database, the user's unique identifier is sent along. Based on the user unique identifier and the set of permissions associated to its role at the time of the request, the database will either accept or reject the request.
Thanks to this, the user's access to an organization's content is automatically revoked when she/he is removed from the said organization.
Google Cloud Functions, that are used to serve our application, live behind the Google Frontend. They are protected against brute force/DDoS attacks the same way that google.com protects itself.
In addition, since Firebase Authentication is the gateway to many of our backend services and security rules, many of our quotas are protected by per-IP limits to give an extra layer of protection against a localized attack.
Last modified 1yr ago