Breeze.js - Securing IQueryable calls

Question

I'm rather new at this, but I've come to understand the security risks of using Breeze to expose an IQueryable<>. Would someone please suggest to me some best practices (or merely some recommendations) for securing an IQueryable collection that's exposed in the JavaScript? Thanks.

Figueroa

It would help to know more about what worries you. Not much to worry about if the type is "StatusCodes". More to think about if it is "Customers". But this is so whether or not IQueryable. Would be best if you enumerated some specific concerns ... and then we can "answer" them. Please do! We all welcome such specificity. – Faint

possible duplicate of How is breeze.js handling security and avoiding exposing business logic – Pasadis

Answer 1

I would not expose any data via IQueryable that should nto be sent to the client via a random query. So a projection could be exposed or a DTO.

I'm not sure if this answers your question tho ... What "security risks" are you worried about?

Silas

Answer 2

I second this question, too. But to add some specifics along the questions that Ward asked:

In securing queryable services, two traditional issues come to mind:

1) Vertical security: Which items is the currently logged in user (based on user identity or roles) NOT allowed to see in the UI. Those need to be removed from the queryable list. IMO, this can be done as part of the queryable ActionFilter magic by chaining some exclude logic on the returned IQueryable. 2) Horizontal security: Some models contain fields that are not appropriate for the logged in user to see (and/or edit). This is more difficult to handle as it's not a matter of just removing instances from the returned IQueryable. The returned class has a different shape and therefore can be handled either by the json formatter omitting the fields based on security (which AFAIK screws up breeze meta data) or you return a DTO in which case since the DTO doesn't exist in the metadata it's not a full life cycle (updatable) class? (I am asking this not stating it)

I would like to see either built-in support or easy to implement recipes for number 2). Perhaps some sample code to amend the client side metadata to make DTOs work perfectly fine comingled with model objects. The newset VS 2012 SPA templates (in the TodoList app) seem to push DTO variants of the model object both on the queryable and insert/update side. This is similar to the traditional MVC modelviews...

Finally - I'd add a request to auto-handling of the overposting security issue for inserts and updates. This is the reciprocal aspect of 2). Some users should not be able to edit certain fields.

Fir

Worthy observations. A big topic ... one I hope to address in the coming months. Your suggestion on "Vertical security" would do; many times you can add the role-based filtering to the query method itself, either in the controller method or (better) in a subclassed ContextProvider which moves business logic out of the controller and into the business model. See next comment for thoughts on "Horizontal" – Faint

"Yes" to recipes. Check out Julie Lerman's Jan MSDN article also on constraining the EF model to suit the domain. As you note, this doesn't help when certain users aren't supposed to see certain values. The Json.NET serializer's ContractResolver may be a good bet here. You can also just write a non-queryable service method that returns an IEnumerable of the requested type; you can query inside that method and manipulate the results in a fine-grained fashion before returning them to the client. All you lose is OData-ish querying; can still send params. To be continued ... – Faint

Re: overposting ... how would you have us automate that? Do you mean guarding against updates to properties that aren't exposed through queries? If so, the first thing to look at is shrinking the entity surface (see Julie's article). Or do you mean posting to properties they can see but shouldn't touch? On you know the rules for that. Are the BeforeSave... methods insufficient? They exist in part for this purpose. – Faint

Regardless, we need to offer some guidance and choices. There is a lot you can do before you fall back to pure DTOs and Command/Query segregation ... which is your ultimate backstop. – Faint

I would like to add that a dynamic server based language would really shine here, as we could just remove the properties from the objects that the user is not allowed to see. – Dubitation