I’ve just been reading about the ASP.Net Web API support for OData queries and I’m having trouble reconciling the external exposure for query filtering, which essentially provides integrators the ability to throw any arbitrary query filters at the database with no regard to optimal query plans, fields that shouldn’t be queried on and so forth.
How does one go about sanitizing the OData query so that the user can’t throw horrible complex queries directly at the database which may cause performance issues, and which may contain references to fields that shouldn’t be executed against?
we are looking at addressing these concerns. Starting with Web API RC we require that you explicitly annotate your method with
[Queryable]to indicate that you want to opt into the automatic filtering behavior. We are also looking at some other extensibility/customization APIs that will become available later.Fundamentally since this is an automatic system it requires some understanding on the part of the developer to know all of the performance/security considerations. In a sense it’s no different than the issue of overposting in parameter model binding (e.g. someone posts a User object that has the IsAdmin property set to true even though your API never documented that it supports such a property. It happens to work because the model type you use on the server also has a IsAdmin property). Such concerns can be addressed by writing specific DTO objects that tightly control what data you expose and accept as input.