Apps created with AppSheet are secure because of the architecture of AppSheet, because of the underlying security infrastructure of cloud and mobile technology, and because of security options in your control.
First, let’s quickly summarize the AppSheet architecture from a security point of view:
- Cloud data: Your data is stored in your cloud data provider (Google Drive, Dropbox, Box, Smartsheet, Office365, etc). AppSheet does not store your data.
- Authorization: As explained in another section, when creating an application, you sign into AppSheet with your cloud storage account and give AppSheet the permission to read and write your cloud storage data on your behalf. The industry standard OAuth protocol is used in this process.
- Apps get built based on the cloud data: The application you create is saved to an application definition that is maintained by AppSheet in a secure cloud database. Communication between the AppSheet cloud service and your cloud storage provider uses secure web protocols (HTTPS).
- The apps run on a mobile device: Communication between the mobile device and the AppSheet cloud service uses secure web protocols (HTTPS).
- Local data storage: The application definition and all the necessary data is copied to the mobile device and securely stored locally on the device using HTML5 local storage.
- Data synchronization: When you add, update, or delete data via the AppSheet application running on your mobile device, all changes you make are saved to your cloud data provider. The AppSheet cloud service acts as a go-between to connect the mobile app with the cloud data provider used by your app.
You may have the following security questions about each of these aspects of AppSheet-- we answer each of them in this article:
- Who can access my cloud data directly?
- Who can access my app and how do I control that?
- Do the users of my app also need to have access to my spreadsheet in cloud storage?
- What can users do with my app? Can they delete my data?
- Can I limit the data that specific users of the app can see?
- Can I limit the actions or capabilities that specific users of the app can do?
- Who can access the data on the mobile device?
- What happens if an app user leaves my organization and I want them to stop using my app?
I will explain these topics using a fictional app created by a teacher to distribute and collect assignments from her students in a graphic design class.
Who can access my cloud data directly?
No other AppSheet user can access your cloud data directly-- that permission lives solely with you (and whoever else has your cloud account’s login info).
Depending on the update permissions you have enabled in the app, the users of your app may be able to add, edit, or delete values that live in your cloud-hosted spreadsheets and that are exposed via the apps you build with AppSheet. You can control these permissions as described later in this article.
The AppSheet cloud service has permissions to act on your behalf to read and write your cloud data. These permissions are only used for the specific purposes of app creation and app execution. AppSheet does not save copies of your data. Furthermore, because of the way the OAuth protocol works, you can at any time decide to disable the access permissions granted to AppSheet.
Who can access my app and how do I control that?
Controlling who has access to your application is a three step process.
- Set the Require user authentication option.
- Choose an authentication provider.
- Specify which users can use your application.
First, set the Require user authentication option by going to the Security > Require Sign-In pane and setting the "Require user authentication" option. If you do this, you must enroll in one of the Pay-Per-User pricing plans when you deploy your application. "Require user authentication" is not supported by any of the Pay-Per-App pricing plans.
Next, select an authentication provider. AppSheet does not maintain its own user registry of usernames and passwords. Instead, users must sign in using a cloud provider such as Google, Dropbox, Office365, Box, or Smartsheet.
- By default, the authentication provider will be the cloud data provider where your data is stored.For example, if your cloud data provider is Google, your default authentication provider will be Google.
- Alternatively, you can choose one of the providers from the "Authentication Provider" drop down list containing Google, Dropbox, Office365, Box, and Smartsheet. For example, even thought you cloud data provider is Google, you can choose Dropbox as your authentication provider. You might choose this option, if all of your app users have Dropbox accounts.
- Finally, you can choose all of the providers including Google, Dropbox, Office365, Box, and Smartsheet. Do this by selecting the blank authentication provider appearing at the top of "Authentication Provider" drop down list.
Finally, specify which users can use your application.
- Normally, you will enter the email address of each user who is allowed to use your application in the "whitelist". Do this by going to the Security > Require Sign-In pane and clicking "Manage user whitelist". Then enter the email address of each user in the "People to invite" list. You can enter multiple email addresses separated by commas. Then click "Send install link".
- Alternatively, you can include all of the users in a domain by clicking "Add Entire Domain" and entering a domain name such as "@mycompany.com".
- Finally, you can avoid entering a whitelist by setting the "Allow all signed-in users" option. Only enable this option when you do not need to restrict access to a specific list of users, but you still want to access user-specific information like their email, or use personalization features like security filters or private tables
Do the users of my app also need to have access to my data in cloud storage?
No. As the app creator, you can distribute your app to people who do not have direct access to your cloud data. This works because the default execution mode ('as app creator'), instructs AppSheet to access data using the identity of the app creator. Normally, you should not allow your users to directly access you cloud data. Instead, they should only be allowed to make changes through your application.
In rare circumstances, you may choose to have your app run as the app user. Find out more in this section. In this case, you must grant your users direct access your data in cloud storage. Only do this if you fully understand the security implications of doing so.
What can users do with my app? Can they delete my data?
As the app creator, you control what changes, if any, users can make to your data. For example, you can control whether the user can add, update, delete, or only read your data.
You can control what changes can be made to a table as follows:
- Go to the Data > Tables pane.
- Click the icon to the left of the table name.
- Choose an access mode from the "Are updates allowed" drop down.
You can control what changes can be made to a slice as follows:
- Go to the Data > Slices pane.
- Click the icon to the left of the slice name.
- Choose an access mode from the "Update mode" drop down.
Can I limit the data that specific users of the app can see?
Users of your app can only see data that you choose to expose through the app. In fact, you might want certain classes of users to only have access to view specific subsets of data, and other users to different data. You can do this using slices.
In the case of the Class Assignments app, I want to make sure that students can submit completed work and continue to view past submissions, but I don’t want them to be able to see the completed work of other students. The best way to do this is to create a slice that shows only the assignments of the logged-in user. I’ll do this from the Editor>Data>Slices tab, then clicking “+Slice”.
First I’ll need to name my slice and then specify a few parameters. In this case I’ll want to choose the “Submit” table so new submissions will end up there. I'll also want to make sure students can only add submissions, and not delete or edit-- so I’ll choose “ADDS_ONLY” as the update mode for the slice.
In order to make sure logged-in students can only see their own present and past submissions, I need to filter based on the Student column. Since I required sign-in for the app, my filter condition should be “Matches user name”-- the app will then only show data that matches the current logged-in user’s name.
You’ll see then, in the hamburger menu, that the current logged-in user’s name shows up.
You’ll see below how the slice ensured Justin A. Sample would only be able to view his own past assignments.
Can I limit the actions or capabilities that specific users of the app can do?
All users of the same app will have the same editing, updating, or deleting capabilities. However, if you’d like different classes of users to have different permissions, the best approach is to create different apps for each user with the corresponding permissions levels. Each app would be tied to the same source spreadsheet. Creating a new app takes just a minute, especially if you start by copying an existing working app.
Who can access the data on the mobile device?
On the mobile device, AppSheet uses industry-standard "local storage" technology associated with web browsers (web browser technology is embedded inside the AppSheet mobile app and the actual implementation largely utilizes HTML5 technology). Since you require users to sign in to access your app, each user's data is isolated from any other user's data. Even were multiple users to use your app from the same device, their data would be isolated as long as they sign into the device as different users. In short, if you follow standard security practices on the device (users sign in with passwords), your app will be as secure as all other apps based on web technologies.
What happens if an app user leaves my organization and I want them to stop using my app?
At any time, you can return to the user whitelist and remove any users you’ve previously added. Any subsequent actions by the removed user from their mobile app will fail when the actions engage with the AppSheet cloud service (typically when synchronizing or saving data).
As an extreme measure, you could also make a copy of the app and delete the old one. The old one will stop working and then you can control access to the new one. You’ll need to make sure to redistribute the new app link to the other users who still need access.
You can find out more about security in our Security and Reliability section.