Problem/Motivation
See #3035979: [DISCUSSION] Should a facility be added to JSON:API which limits automatic exposure of all entities for prior related discussion.
In #3035979-14: [DISCUSSION] Should a facility be added to JSON:API which limits automatic exposure of all entities, @greggles said:
[Drupal 8's HTTP APIs are] shining light on some code paths that are not as well hardened as the rest of Drupal. As a community of developers and site builders our sophistication around writing and testing these kinds of sites is advancing.
In other words, if the "First" in API-First means making APIs a first-class citizen (i.e., making everything a site can do via HTML also accessible via APIs), then that's a great design principle and goal. However, we also need to be aware of Drupal's actual history, where HTML came "first" (chronologically), and it's taking time for Drupal contrib and custom module developers to adjust to the security implications surfaced by HTTP APIs.
For example:
- One can write an entity type for which there is no HTML route at which it can be viewed independently of being edited (this is common for config entity types, but can also include content entity types). And in the process of doing so, one can accidentally introduce an access control handler that allows 'view' permission to someone who does not have 'edit' permission. And not realize this until someone is able to get that entity data via an HTTP API, that they can't get via HTML.
- The above can also happen for individual fields within a given entity type or within any entity type.
- One can write an entity type or a field whose HTML form (via Drupal's Form API) performs critical input validation that isn't performed by the entity type's or fields' validation constraints or serialization denormalizers. And again, not realize this until someone is able to corrupt the data and/or exploit something via that corrupted data, in a way that they can't do via the HTML form.
Ideally, all module developers would know about all these pitfalls, and code all of their entity types, field types, validation constraints, normalizers, and access control handlers, correctly and securely. And also, have as much automated testing and perform as much manual testing, for HTTP API usage of their module's features, as they do for the HTML usage. But, we're not there yet.
So, let's figure out what, if any, additional safeguards and mitigations could be added without harming the DX and UX for people working with Drupal for API-First projects.
Proposed resolution
Several ideas were proposed throughout #3035979: [DISCUSSION] Should a facility be added to JSON:API which limits automatic exposure of all entities. Let's add child issues for ones we want to explore further.
Remaining tasks
Issues yet to be filed:
- A simple status report message indicating JSON:API's read/write status (proposal from UX team meeting that we agreed was not a hard blocker and could use further discussion).
- An issue for:
"Limit to accessed API's" or something as a starting point when you go into production.
...potentially dependent on #1537198: Add a Production/Development Toggle To Core.
- Potential issues for @gabesullice's ideas in #3.
- Ideas for promoting further security research on contrib code with JSON:API. Many contrib vulnerabilities continue to be found with REST, and if they also exist for JSON:API they become more severe because of JSON:API's more permissive configuration.
- Ideas for educating developers about writing secure code for an API-first Drupal.
- Other issues to harden the "GET everything by default" configuration.
- Issues for mitigating risks relating to config entities.