Multiple mechanisms have been put in place to help protect your data:

👉🏽 Expose pre-defined data through persisted queries, and avoid granting public access to the single endpoint.

👉🏽 Create custom endpoints, accessible only to the intended target user or application

👉🏽 The single endpoint, and clients to interact with it, are disabled by default.

👉🏽 Grant granular access to the schema via access control rules, down to the operation, field and directive level.

👉🏽 Define the API to be either public or private.

👉🏽 Which settings (from table wp_options) and meta values (from tables wp_postmeta, wp_usermeta, wp_commentmeta and wp_taxonomymeta) can be queried must be explicitly defined in the configuration.

👉🏽 Some fields and input fields are exposed as “sensitive” data elements", as to provide access to private data, but have it disabled by default: public data (eg: posts) is accessible by default, private data from the user (myPosts) is available to the logged-in user, and input status in field posts(filter:) (to retrieve non-published posts) is accessible only if explicitly enabled.

👉🏽 The admin can grant user-role access to editing the schema.

This image shows how we can grant access to editing the schema based on the user role: