You are asking important questions. It is true that the path we show is a direct line from the database tables and columns to the JavaScript client. That is the easiest path and is typically harmless. While you may not need every column exposed as a property on the client, it is harmless to do so most of the time.

But sometimes it matters and matters a great deal. Then you have to take steps.

The first thing to understand is that you do not have to expose every server-side entity to the client. Personally, I would not ever send a credit card number to the client. If I accept a credit card from the client, I do so in a command from the client (via a separate API for that purpose). But I don't send it back and it would be no where in available for reading from my service API.

Second, you can define types that exclude server-side entity properties that should not be sent to the client. My preferred practice is to split the table (or the entity type in the ORM) so sensitive information is in a related table (entity) in a 1-1 relationship. For example: Customer and CustomerConfidential.  Following my first piece of advice, only the Customer entity would appear in my Service model.

Third, you can define a projected type. Suppose that you cannot split Customer. You could define a projected type that has only the safe properties (call it CustomerSafe for this example). You'll have to do some processing to make this work; but you are already committed to writing that code by virtue of your concern for safety and the fact that you couldn't factor your original model. The work is no greater than if you resorted to traditional DTOs and at least you're doing this work for the few types that need this treatment; you are not imposing this tedium on every type, safe or not, as some other folks would have you do.

The strategy is roughly as follows:

1) define the CustomerSafe type.

2) define a Breeze controller method that exposes only the CustomerSafe type (not the full Customer); the implementation selects the data from the server-side Customer into new CustomerSafe objects. Make sure the property names on CustomerSafe are the same as on Customer.

3) On the JS client-side, add a CustomerSafe type to the MetadataStore. Yes you can define types on the JS client; they don't have to be in the metadata coming from the server. We haven't documented how to do this yet but we will.

4) Intercept saved changes to CustomerSafe entities in your server-side Breeze SaveInterceptor. Translate them into server-side Customer objects, save them yourself, remove them from the SaveBundle, and let the EFContextProvider save whatever else needs saving (optional).

I can think of other ways to do this too. Remember you can always step outside of the Breeze Query and SaveChanges mechanisms to get and put/post data through other service APIs. As long as you can define the type on client-side metadata (step #3 above), the entity can behave like any other Breeze entity while on the client. You just intervene at the query and save points to re-direct the data through some other API (perhaps with regular AJAX calls). Again, this is no worse than what'd you'd do if you had your own data layer. And the good news is that you're only doing this kind of thing at the boundaries of the system. You don't have to do it for any of the other types and the CustomerSafe gets to participate in the caching, entity navigation, validation, data binding, etc. that Breeze provides for all other entities.

Finally, if you just don't like the name "CreditCard" on the client because you think it sends the wrong message ... change the name. Do that on the server if you can. If you can't, you can change it on the Breeze client by defining your own NamingConvention to give it a different client-side name.

All of this is unnecessary 95% of the time. The property names and values of most entity types rarely pose a business risk. You shouldn't have to work hard 95% of the time just so you can cope with the rare 5%. But you should have a way to deal with the 5% when it occurs. And you do, even if it demands a bit more attention and work.

Hope this helps.

However, my concern is more about possible security leak. That is, column names and table names are exposed generously and even the names in the model refer to the content that are stored in the database.

Let me give a specific example.  Suppose that we are a e-commerce site.  Suppose that we have a bit type column, namely CreditCard.  We store if the customer used his/her CreditCard we save customer to somewhere if a person who look at js code when see something like 

"var query1b = EntityQuery.from(“Customers”)

we are writing all queries in to js and giving columns name table name etc..

what can we do for security ?

what is your suggestion?