When will this module get a security advisory coverage?

Deno,

This is a complicated question, regardless thanks for bringing it up. The short answer is yes, this module will get security coverage down the line. The current major limitation to this is that we still need to determine if the data generated by the module needs to have any access control around it, and how to handle that. For example, the module currently generates schema and routes for all available api endpoints. Nothing special is implemented in order to prevent this list from including routes and entity schema which the user won't be able to access or interact with. While this is strictly not a security leak, as it won't expose entity records, it still could potentially be used to understand the structure of those site components. In the short term, this information is protected by a permission, meaning that the admin has to grant users access to site schema, and thus knowingly is distributing this information to approved users. Long term, this module should take into account the entity types, fields, and permissions which a given user has in order to reduce the returned results to only those endpoints and entity types for which the user should be able to work with.

The choice to opt the module into coverage then falls to if the given permission is seen as sufficient enough to be considered secure and the amount of work required to make it sufficient. I do feel that this is a priority of mine for the module, but haven't felt like the module and schemata, which it depends on for schema building, have reached a point where they are stable and not subject to api changes which may cause access leaks even after more advanced access checks have been implemented. As a result, I can't tie a specific timeline to opting in this module.

Then again, maybe I am thinking two much into security coverage, and the module as it stands now is sufficient. Let me know you have any thoughts.

Thanks for the input. I do agree that not cleaning up entity structure seems like a trivial concept, however depending on the application it can be considered data leakage, if protected field information is being exposed. Much of the time field information would need to be coupled with another insecure configuration in order to cause an entity data leakage. An example of this might be the existence of a field which is typically excluded from jsonapi, and typically used for an administrative filter. This module exposing documentation on that field could in theory use the knowledge to expose that information through jsonapi. This use case isn't strictly a vulnerability in this module but not respecting disabled/hidden entity fields for jsonapi output could make it easier for a malicious user to exploit another module.

Maybe you consider this poor design, which i wouldn't necessarily argue is wrong, however their may be valid cases for designing an api that way.

Is this a reason not to enable security support? I don't know if I have the answer to that, as I haven't fully explored the use cases.

As another piece of information, I hadn't deeply considered why this project wasn't already opted into security updates. I took over the maintenance and development of OpenAPI about a year ago, and the module hadn't been opted in at that point. The fact that the module isn't now, is simply the result of no one bringing it up previously. However, I still think that the security implications of this module should still be considered prior to flipping that toggle, as with it comes a sign of trust that the module won't be the cause of an exploit.