No, IQueryable alone is not an injection proof, because it is just an interface for building an Expression query. It does not define how to take this Expression and turn it into something executable, such as SQL. What it is is a Provider query (many exist. Linq to Objects, Linq to Entities, Linq to Excel, to name a few).
However, your example, which appears to be using DynamicLinq (based on the use of the .Where(string) extension), should have similar parameter protections, such as regular Linq to Entities IQueryable . DynamicLinq does not present any additional problems with SQL injections, as it is just a utility working on top of IQueryable . Everything he does is simply translated into an expression tree, which again depends on the Provider , to actually translate into SQL. This does not mean that the DynamicLinq syntax itself is safe from its own injection potential (see here for some examples, but this is not an SQL injection).
Microsoft has this to say about LINQ for Entities and SQL injection:
Security Considerations (Entity Framework)
Although the composition of queries is possible in LINQ to Entities, it is executed through the object model API. Unlike Entity SQL queries, LINQ to Entities queries are not composed using string manipulation or concatenation, and they are not susceptible to traditional SQL injection attacks.
This means that your DynamicLinq built by IQueryable (when using LINQ to Entities as a provider) should still parameterize the input. If your question is really βIs LINQ to Entities an injectable proof?β, Then the best answer I could give is βThey probably did all reasonable to protect against it.β
Ocelot20
source share