Headless Server Developer Manual / Version 2301
Table Of ContentsDepending on the frontend approach, the Headless Server may be fully or partially exposed to public access. Therefore, the Headless Server needs an effective protection.
GraphQL offers a self-descriptive approach to deliver data to client applications. This makes it easy to any client to use and visualize this data in any way, without the need to have an exact knowledge about the underlying data model, thus reducing the need for support. On the other hand, clients may request as much data as they wish, creating potentially high load on the server.
Warning
Because of the database character of any GraphQL endpoint, the publicly accessible documents should never contain any confidential data, like access credentials or user data.
Protecting the Headless Server can be realized by two general approaches:
- Externally, before the Headless Server is actually invoked, by using hardware (load balancers, firewalls), a web server (gateway) or a so-called backend-for-frontend approach.
- On the application layer of the Headless Server by means of configuration.
The external approach is usually very efficient. You may enforce certain access restrictions by employing some kind of authorization and/or authentication or define IP access restrictions. However, this approach implies, that the clients are in some kind 'known' by the server. If you want to allow accessing data by any client, this approach is hard to enforce.
Whenever it is not possible or not desirable to restrict access to known clients, you might use the application layer approach.
The Headless Server offers these options to employ security measures:
Whitelisting of persisted GraphQL queries described in Section 3.5.1, “Whitelisting of GraphQL Queries”.
-
Blocking of documents, especially
CMSettingsdocuments, from delivery, using their repository path. See the deployment manual Section 3.3, “Headless Server Properties” in Deployment Manual for details about the configuration propertycaas.graphql.repository-path-exclude-patterns. Limiting the size of a search result described in Section 3.5.2, “Limiting the Size of a Search Result”.
Limiting the depth of a GraphQL query described in Section 3.5.3, “Limiting the Depth of a GraphQL Query”.
Limiting the complexity of a GraphQL query described in Section 3.5.4, “Limiting the Complexity of a GraphQL Query”.
Enforce an execution timeout for GraphQL queries described in Section 3.5.5, “Enforcing an Execution Timeout for GraphQL Queries”.
All the above measures may be used to protect the server from expensive queries or malicious attacks.
Note
In order to provide a certain amount of protection by default, the size of a search result is limited to 200 hits and the maximum query depth is set to 30. Especially on protected preview servers, these limits are possibly not desirable, while developing or testing GraphQL queries and therefore should be reconfigured to suite your needs.
