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.