No, IQueryable
itself is not injection proof because it is just an interface for building a query Expression
. It does not define how to take that Expression
and turn it into something to be executed, such as SQL. What does perform this is the query Provider
(many exists. Linq to Objects, Linq to Entities, Linq to Excel, to name a few).
That said, your example which seems to use DynamicLinq (based on the .Where(string)
extension use) should have similar parameterization protections as regular Linq to Entities IQueryable
's. DynamicLinq doesn't introduce any additional SQL injection concerns, because it's just a utility that works on top of IQueryable
. Everything it does is just translated to an expression tree that again depends on the Provider
to actually translate to SQL. That doesn't mean that the DynamicLinq syntax itself is safe from its own injection potential (see here for some examples, but these are not SQL injection).
Microsoft has this to say about LINQ to Entities and SQL injection:
Security Considerations (Entity Framework)
Although query composition is possible in LINQ to Entities, it is performed through the object model API. Unlike Entity SQL queries, LINQ to Entities queries are not composed by using string manipulation or concatenation, and they are not susceptible to traditional SQL injection attacks.
This means your DynamicLinq built IQueryable (if using LINQ to Entities as the provider) should still parameterize inputs. If your question is really "Is LINQ to Entities injection proof?", then the best answer I could give is "Probably. They have made all reasonable efforts to protect against it.".