Contrib.social

Introduce entity type annotation key for indicating that an entity type is *safe* for HTTP API usage

Open on Drupal.org →
Created on 14 March 2019, almost 6 years ago
Updated 30 January 2023, almost 2 years ago

Problem/Motivation

Per #3040025: [meta] Decide on and implement additional security hardenings for JSON:API and other HTTP APIs → , there likely exist contrib/custom entity/field types that have not been programmed with API usage in mind. With JSON:API, the entity types are available for API usage anyway, and the field types are as well if there are fields of that type on any of the entity types. This leads to potential security exploits. With REST, the entity types are not exposed by default, but can be configured to be, by a site builder who is nowhere informed about whether the entity type is safe to expose or not. And just as with JSON:API, REST exposes all of the fields that are on an exposed entity type.

Proposed resolution

Option 1:

Close this issue as "works as designed", and do more to educate contrib/custom module developers on how to write secure entity and field types for an API-First world. For example, https://www.drupal.org/docs/8/modules/jsonapi/security-considerations → .

Option 2:

Introduce an api_consumable annotation key that defaults to FALSE. Contrib/custom module maintainers then have to explicitly set it to TRUE for their entity (descoped) types to be available for API usage. Thereby, module maintainers who haven't thought about the implications of their entity (descoped) types being used by HTTP APIs are secure by default. And at the time that they want to enable API usage of their entity types, then they can set that annotation and educate themselves on the security considerations.

This proposed annotation is different from the existing internal annotation key in several ways:

Option 3:

Separate reading and writing, by introducing api_readable and api_writable annotation keys. This would allow an entity or field type to say "my type is prepared to be read via HTTP APIs" without having to yet say "my type is prepared to be edited via HTTP APIs". Since it's easier to secure reading than writing, this provides an incremental path to module developers. It also reflects an implicit reality that already exists in core (config entities are currently API readable but not API writable), so this would give us a way to be explicit about it. On the other hand, #3037039-17: Create a public API for indicating resource types should not be exposed → argues that it has the risk of encouraging too many module developers to make things readable but not writable, and that's ultimately not what we want.

Remaining tasks

Discuss the options and decide on how to proceed.

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Needs work

Version

10.1 ✨

Component
Entity  →

Last updated about 5 hours ago

Created by

🇺🇸United States effulgentsia

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024