I need a primer web/javascript security.
According to How to use an HTML/JavaScript client for Windows Azure Mobile Services, in javascript on the client side, after including a link to MobileServices.Web-1.0.0.min.js you're supposed to create a client like this:
var MobileServiceClient = WindowsAzure.MobileServiceClient;
var client = new MobileServiceClient('AppUrl', 'AppKey');
which means including my AppKey in the javascript on the page. Should I be worried about the AppKey being public?
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in. The usefulness of this is somewhat reduced with a cross-origin resource sharing whitelist, but what's to stop someone with this information from adding javascript to the page and executing arbitrary operations on my backend database? Restricting table permissions to authenticated users wouldn't help in this scenario.
Do I need to be concerned? What do banking apps do about this sort of thing?
In the same link which you shared, application key is defined as a not safe mechanism to authenticate users - A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
More over when you enable some authentication on all the endpoints either using ACS or through Open Authentication, if you main ASP.Net/PHP etc page got authorized, then browser is going to handle federation of identity through cookies for next on-going calls till your session ends.
In most of the applications having HTTPS would protect from Man in middle attacks. Also strong encryption logic on cookies along with very specific expiry times would increase the bar of security. Also IP address based checks would definitely help in improving security.
ramiramilu's answer covers most of the question. There's one more thing which I'll add:
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in
Yes, someone can add a breakpoint and find out the value of the X-ZUMO-AUTH header which they're sending. But the value of that header is specific for the logged in user (in this case it would be the "attacker" [him/her]self) - it wouldn't be able to get information from other people out of that header. And there are even easier ways to get the value of that header (just browse to https://<mobileservicename>.azure-mobile.net/login/<authProvider> and after entering your credentials you'll see the header encoded in the URI).
