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_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: