G'day Sergio,
thanks for your considered reply. I certainly think there needs to be wide spread discussion on the matter, as it concerns me that such a simple requirement isn't available as part of core xsodata.
While HTTPS is a must for practically any web app, it doesn't resolve the issue of querying the odata entity for all records once you are an authenticated user of the app. Headers are available on the client side. The same can be done for Fiori apps within the corporate network. Using any modern browser, you can quite easily see the odata service queries sent from UI5 and replicate them in Postman, or suchlike.
I use a reverse proxy to help with some of these issues, as you alluded to with Web Dispatcher (I don't use WD however). But take for example, a RESTful CRUD service built on Node and Express - each type of call (GET, POST, DELETE, PUT) will have a JS code implementation. A GET request might have some simple code to read results for the query, but also ensure that the records belong to the querying user (identified by session/bearer token/etc). POST may also do some checks before writing to the DB. xsodata offers modification exits for delete, update, and create, but not read. This is perplexing, in the least, and would immediately solve this problem.
Of course, the point of xsodata is to remove the need for such coding, but there's a gaping hole in simple security for read operations. I guess this is more of a venting session than anything 
It's odd that more developers haven't identified the same problem...
In any case, thank you again for your thoughts Sergio - perhaps, given your credentials, you may have access to someone that could at least explain this interesting omission, or propose a simple solution?
Best,
Hagen