Security FAQ
Last updated
Last updated
GitBook is a tech startup, incorporated in the U.S as GitBook Inc , with a French subsidiary GitBook SAS
We are hosted on , 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 .
Yes, all customer data is encrypted at rest and in-transit:
In transit, we use HTTPS to encrypt all traffic served to end-users.
Even user-provided custom domains are covered, thanks to and Cloudflare.
At rest on Google Cloud Platform, using .
By default, all customer data, unless explicitly public, can only be accessed by authenticated users with valid permissions.
The only required piece of information to sign up and start using GitBook is an email address.
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 a 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.
Thanks to this, the user's access to an organization's content is automatically revoked when she/he is removed from the said organization.
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.
You can control and restrict access through our , allowing you to invite external members to join your organization and collaborate, whilst restricting their access to a chosen subset of your projects.
Depending on the risk evaluation performed using the , 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 only.
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.
for Search
for Payments
for Support
for Sign up risk evaluation
and for Analytics
for hosting (data & compute)
These permissions are then applied directly at the database level, thanks to the . For each request that reaches our database, the user's unique identifier is sent along. Based on the user's unique identifier and the set of permissions associated with its role at the time of the request, the database will either accept or reject the request.
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 protects itself.
Yes, we are. You can read more about value and our certification on the next page.