CODEWITHSUNDEEP
odataasp.net-web-api
Nathan Ridley
Nathan Ridley

Reputation: 34396

ASP.Net Web API OData - Consumers have free reign to query whatever and however they want?

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?

Upvotes: 2

Views: 1922

Answers (3)

Regfor
Regfor

Reputation: 8101

Web API has special handlers mechanism. So you can check and process queries that are going from user.

http://www.asp.net/web-api/overview/working-with-http/http-message-handlers

But for OData queries it's not common to expose IQueryable from database. Common approach is to make general query, "pre-queried" on server and than give user ability to query or filter this prequeried result. And than you will be sure that user wasn't able to make query "wider" than prequeried result.

And as a note: WebAPI has only support for filter, top, skip, orderby. So very limited. For normal OData support - use WCF Data Services

When you want to hide from user filtering/querying some columns, than one way is writing custom handler that will parse URI from user and return e.g. 403 error, or as a variant to make DTOs objects without these columns and expose them for "pre-query" to user.

Upvotes: 1

marcind
marcind

Reputation: 53183

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.

Upvotes: 2

Darrel Miller
Darrel Miller

Reputation: 142174

In my opinion, this is a architectural tradeoff of using the OData query syntax. If you don't want people to have unconstrained query access, don't use it. It's the same, SQL Views versus SQL Stored procedures argument.

Upvotes: 1

Related Questions