6bee
commented
3 months ago Hi, great question!
Remote linq, i.e. Remote.Linq.EntityFramework and Remote.Linq.EntityFrameworkCore for that matter, do not deal with SQL whatsoever. They simply apply linq expressions to EF which takes care of translating these expressions to SQL as is done when using EF in a traditional way.
However, there are security concerns to be considered. Since queries typically are composed on client tier, the client gets more power and flexibility as the server's API is not as restricted as it typically would be e.g. exposing a WebAPI with well defined methods and parameters. Here are some aspects to be considered:
- Least privilege: Both server and DB should be protected and restrict access to what's required. E.g. for read-only access make sure the DB user is granted read-access for required tables only.
- Minimal entity model: The entity model should be designed according the use case and not expose additional data.
- Query complexity: For production systems, performance testing and optimization may be an important concern. The fact that the queries are defined on the client tier may be an issue if you're not in control of client development. While this is probably not in issue for internal applications, public or external apps/services must have effective DoS prevention in place.
What's more, for more advanced scenarios you may want to have a look at aqua-accesscontrol which allows restricting fine grained access for linq queries/expressions on global level, entity level, and property level. The library has not been actively maintained for a while but I'm happy to give it an update in case you're interested. Have a look at some unit tests to get an idea of how to use it: Aqua.AccessControl.Tests/When_applying_type_predicate_with_linq_to_object.cs
MatteoZampariniDev
Hi! I'm interested in this library, is there any concern about SQL injection or similar?