How is breeze.js handling security and avoiding exposing business logic

Question

We are considering breeze js to build enterprise applications.

The awesomeness of breeze is that we can execute queries right from the client browser. This allows to constructs dynamic queries based on the users input without loading unnecessary data. I have found that using Breeze we can create business logic that reduces data traveling/transferring by 1/10 or even more when using a lazy loading strategy. using queries like these

Hooray breeze!!!

But what about Business Logic security, For example, We could have a repository in which we could conceal, hide and obscure our business logic; and then use MVC Web API controllers to just make calls to those repository C# classes. so Breeze JavaScript talks to the WebAPi controller and the WebApi controller talks to the C# repository. The Controllers will always be kept very simple and easy to read, but the Repository may end up having lots of business logic for the company using the application. So if a hacker uses, for example, the Google Chrome developer's console to inspect the JavaScript code, all he/she will see are things like GetCustomers(), GetProductsForThisId(54). There is not much information that can be seen (or stolen) there. Because 90% of the Business Logic will live on the C# repository on the server .

How is breeze.js handling that ?

If we start moving the queries and business logic "from the controller's C# to the breeze JavaScript", we have to consider that our system is membership based. I think the more queries we expose to the client in JavaScript, the more vulnerable our software becomes, and the more we tell hackers how to hack our website and possibly steal information.

Tertiary

Answer 1

Security is a vital concern. It is wise to think carefully about the data and logic exposed on the client. How can we refine these sentiments into a concrete question suitable for an SO answer?

Nothing about Breeze should cause you to expose business logic to the JavaScript client. You can (and should) lock such logic safely inside your repositories and/or controller methods.

But I struggle to understand how client queries themselves are the kinds of business logic that need protecting. Where's the danger in a query for a customer whose name begins with 'A'?

You may rightly worry about a query for customers with net worth > $100,000. But the fault is not in the query. The fault would be in exposing such customer information to unauthorized users by any means, whether through a Breeze where clause appended to a query or a call to a service named GetCustomers().

The place to block unauthorized access to customers is on the server and you can do that as easily inside a Breeze controller action method returning IQueryable as you can in your GetCustomer() method. The burden falls on you in either case to impose the necessary security constraints on your controller and within the methods that you expose.

You write the controller. You write the repositories. You have access to the user's permissions. You are in complete control with an uncompromised ability to expose as much or as little as you wish.

FWIW, your Breeze EntityManager can call service methods that do not return IQueryable<Customer>. It can call Web Api controller methods such as IEnumerable<Customer> GetCustomers() or Product GetProductForId(int id). In my opinion you will lose the flexibility of Breeze's query facilities without gaining any security. But that's just my opinion. Breeze will support your choice, whatever it may be.

I'd be happy to try to answer a more specific "how to" question.

Osswald

I guess the worry here is if there are queries where rows weren't meant for the user. It opens a can of worms. Probably more of a concern when you bolt this on to an existing app. But if you design your system with breeze in mind I think queries should be fine – Gattis

That can be an important security constraint ... and one you must enforce on the server with full and certain knowledge of the user. That's work to be sure no matter how you construct your server-side API. Breeze doesn't help you much with this kind of thing ... but it doesn't stand in the way either. – Osswald

@Ward, I don't understand your answer. I think the query facility does expose a risk and I don't see how to prevent the risk. Let's say the server exposes a query entry point for an unrestricted entity that is related to a restricted entity. I'll write the client to never include the restricted entity, but a malicious client could request it. How do I write the server to prevent this? I totally agree that I need to "impose the necessary security constraints" and "enforce on the server", but the question is how do I do that? Do I analyze the query? Inspect each entity of the query result? – Chairwoman

Answer 2

would like to add that you can restrict users that are not authorized from quering by using the attributes in webapi if you get 401 code back from the server just popup a login screen and redo the work needed after the user is logged in

so a user may try to get data about an order but he won't get it unless he is authorized to do so

Allies

Answer 3

You can to a lot of stuff using breeze.js First of all check my answer regarding security here

How to handle authorization with Breeze JS?

Also although breeze.js can be used like a normal ORM on the client (which can be extremely helpful at times), you should keep your business logic in web api controllers and expose only the necessary stuff using OData queries. If you need any data manipulation logic, then you should do it on the server using a specific method for that.

Only UI logic should be present on the client, also consider that there are several performance implications if you start performing multiple queries directly from the client. Either expand the entity graph to load more results or use more specialized methods that return object. Breeze will introspect the results and consume the entities happily without implications.

Uneven