Hello,
This question came from a lot of clients and projects where data protection is a must.
In some projects, we are being told to always use Data Actions instead of screen Aggregates. And that rule comes from the fact that using screen Aggregates cause a security risk by giving information about the entities that belong to the aggregate and all the attributes that they have, with the same schema of the database.
This is not a critical issue but it is indeed a big deal when we are talking about facilitating an attack to the database, since the attacker can know about the database schema and how to build the query's.
You can see below an example of that information in chrome inspect:
Even having some fields empty (like user's information) it is still possible to understand that there are 3 tables, some foreign keys (like InvoiceId) and that the current screen information comes from these 3 entities.
I believe that this information should not be available on client side. The API response from that aggregate should adapt to the needs in the screen and build the JSON according to it.
For example, in this screen, since I'm only showing data in a table with some attributes, then the response of the API should be something like:
[ { "Code": "code", "Date": "date", "Remarks": "remarks", "Item": "item", "Value": 0, "Name": "name" }]
What do you think of that? Should OutSystems ensure this?
Regards
yes, if datamodel is secret, you need to put a wrapper module between CS and UI, and only reference structures from the wrapper module in the UI module
For what I investigate, this issue falls into the following OWASP Top 10 API Security Risks
https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
Hi @Tiago Rodrigues ,
if you need to protect your datamodel, the only way I have found to work, is to not reference the CS module at all in the UI module.
So you need a wrapper module, with public structures that only hold the information that you want to be visible to everybody that can acces your front end.
And so yes you need a data action; but that is not enough, inside the dataaction you need to call server actions from that wrapper module.
So this is much bigger of a change than just replacing aggregates by data actions.
Dorine
Hi @Dorine Boudry!
Thanks for the help.
I'm curious :) why do you say that it is not safe enough to have Data Actions and why do you indicated that we need to isolate the tables in that way?
I did a quick test using a DataAction instead of a Screen Aggregate (images below), and the DataAction API response did appear only according with the structure I define (without any information about the DB).
Where do you see the security issue in the DataAction this way?
Screen Aggregate:
Data Action:
Thanks!
Best regards,
Tiago
in the model.js file(s)
Thanks a lot for this info. Indeed we can see the database structure on the model.js file because OutSystems also creates client classes based directly on the entities to use them on the code.
That is also an issue to consider in terms of security.
Hi @Dorine Boudry
I came across a post describing a similar issue, but in our case, we don’t want to expose the response structure from the Data Action. Since it behaves like an API call, we’d like to know if there’s a way to hide the structure from being visible in the browser. If encryption is the only option, could you please suggest what type of encryption would be most suitable in this scenario?
Thanks in advance
Balaji