Comment on page
GitBook is a tech startup, incorporated in the U.S as
GitBook Inc, with a French subsidiary
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.
Yes, all customer data is encrypted at rest and in-transit:
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.
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 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.
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'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.
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.
Last modified 1mo ago