Documentation review of the "Security Considerations" page

From @jhodgdon in #3039568-66: Add a read-only mode to JSON:API:

b) On the security page at the bottom, it says that if you use read-only mode, that "completely eliminates" security problems... but is that really true? What if reading data is a possible access violation? Maybe that sentence could be changed to say that it would eliminate security problems that could affect the content of your site.

If the page actually says that, we definitely need to remove it. That's something that should never be said of anything, ever. Assume everything has vulnerabilities, somewhere. Information disclosure is certainly still possible, and some other exploits might be able to bypass the protection of read-only mode.

Updating the title because I think others (like @jhodgdon) also have useful input here.

There we go. :)

Hmmm I still think this is not a claim we should ever make:

This completely eliminates hypothetical, as-yet-unknown bugs in preexisting validation constraints and write logic

I would say "mitigates risks from" rather than "completely eliminates".

Regarding this header:

The importance of using stable contributed modules

I think that what's after that header applies regardless of whether or not you're using stable contrib modules. For defense in depth, auditing entity access and restricting access to unneeded resource should be recommmended even if you're using contrib also covered by the sec team. Edit: I'd give each of those things their own header, actually.

Couple other suggestions:

1. The section on read-only mode should probably be changed to clarify that read-only mode is the default, and is recommended for any sites that don't have a need to update data over REST.
2. Under "Bugs in entity types, field types and data types can lead to security vulnerabilities", I think there's more to it than just HTTP APIs being more easily accessible. There's three parts:
   • HTTP APIs are more easily accessible (easier to script attacks, and the same workflow in browsers will often have additional mitigations beyond what the entity and routing systems provide)
   • Drupal historically relied on form validation handling, so security research and hardening for HTTP APIs is still ongoing. (Plus the bit about needing to shift Drupal devs to an API-first mentality generally.)
   • JSON:API in particular is much more permissive to REST, link to page about its no-config DX principle, but this means that site owners need to pay more attention than they do with REST which turns on very little by default.

More on the idea:

If no writes are allowed at all, validation constraints and write logic are never executed, therefore any hypothetical vulnerabilities in them are impossible to exploit.

I believe we've seen now 2 different RCE by anonymous where the team could only consider exploit via POST and other researchers found exploits via GET. I don't have links to the research readily at hand, but I think it's fair to say that the attack surface is greatly reduced but not completely closed.

I've just read the page - my only feedback: maybe the "internal" bullet point could link to some documentation page about what that is?

Otherwise seems great!

Thanks @greggles!

I think https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... might be the best reference to link?

Okeydoke - added it in.

I think leave open for a bit at least.

(fixing my credit, in case it matters and to default for the future)

Agreed, thanks!