There are no built in security features for protecting data in AWAs however there are ways to achieve it.
You may be aware that you can find out the user's Email or Display Name from Sharepoint using the UserDisplayName() and UserEmailAddress() functions. One or other of these (note that only the email address is unique) gives you the identity of the user which can be used to look up a record in a Users table (or similar) which could hold information about their access rights. Let me give you two examples of how this is used in my apps (which I sell on the Sharepoint App Store):
1. In my HR app, KasPer PRO, where every employee could be a user, I have 3 types of user access - Admin User which means they have access to the whole system, Employee Self Service which means they have access to their own information only and Manager Self Service white means they have access (through the Self Service screen) to their own data and that of their reports.
To determine Admin access, each of the full featured screens runs a macro to check whether the user is an admin user or not (which is actually set in a global variable in the OnStart process). If they are not admin users then the system gives them a message and returns them to the About screen.
Also in OnStart, I set another global variable [CurrentUserEmpID] which is used for many things - but for Self Service the system uses this in a Requery macro action when the Self Service view loads so that they can only see their own record. Note that for Employees, I now present their Self Service view in a 'standalone' form (i.e. without all the navigation elements etc.) - see my blog post for how to do this:
http://peoplemanageapps.blogspot.co.uk/2015/01/using-standalone-views-in-access-web.html
2. In my CRM solution, KasCur PRO, I needed to do something a little different. Customers wanted to be able to limit users to only see records which they 'owned'. The system already had a field called 'our contact' against records so I have used this as a basis for security (combined with CurrentUserID determined in the same way as above but checking a Users table).
To make this more sophisticated, each user has 3 possible levels of access to each of the main areas of the system (Companies, Contacts, Opportunities and Support Calls):
Access to All Records
Access to Own Records
No Access
I then use an onload macro to determine access level and apply a filter (or not) or refuse access and return the user to a safe place.
Note that all of this relies on the fact that users must not have the ability to click the Customise in Access option (and therefore open the database in design view). I believe this can be done in Sharepoint Security but, in my view, a better way is to use the Save As option to publish the database 'Locked' to your App Catalog (via an APP file). This allows you to configure a development and live setup because the published databases can be upgraded with new releases published from your development version. There is information about this online.
I know this was a very long answer but hopefully you will find some ideas you can use in here!
