The most basic security feature is user sign-in.
If your app has any confidential data whatsoever, you should require user sign-in.
If your app needs to distinguish between users in a secure/reliable way, you should require user sign-in.
There are five levels of security afforded to apps that require users to sign-in:
Requiring sign-in with a specific provider - only users with an account hosted by a specific provider (eg: Google or Dropbox or Office365) can access the app.
Specifying a user allow list - only specific users explicitly listed in an allow list can access the app. You can learn more about granting application access and revoking it. One approach to this is using domain groups, which you can learn about here.
Utilizing security filters - the app can be configured to show different subsets of data to different users.
Using expression logic within the app based on the USEREMAIL() and USERNAME() functions to customize the app on a per-user basis.
Auditing - the app can explicitly capture the identity of each user who makes a change to the app. Additionally, the audit history automatically captures the identity of every user who interacts with the app.
None of these security mechanisms are available to apps that disable the user sign-in feature.
How does this affect the choice of subscription plan?
We provide five different plans: Starter, Core, Enterprise Standard, Enterprise Plus, and Publisher Pro. Only Starter, Core, Enterprise Standard and Enterprise Plus plans support user sign-in; Publisher Pro only supports creation of publicly accessible applications that don't contain sensitive data and don't require sign-in.
If your app's data is sensitive, then you should require sign-in, and therefore sign up for the Starter, Core, and Enterprise subscriptions.
How public is an app on a Publisher Pro plan?
If you deploy an app on a Publisher Pro plan, you should assume that all the data in the app is visible to anybody. Furthermore, you should assume that anybody who wants can run the app. If the app permits data changes, then anybody can make those changes.
Can I secure an app without making users sign-in?
This question comes up occasionally from app creators who want to use one of the public Publisher plans. The answer is no.
Some app creators try to create their own workarounds for each of these levels of security. However, these approaches all have their shortcomings.
Instead of an allow list, can I control distribution of the app install link?
While this is possible initially when the app creator sends the install link to other users, there is no way to control who those users send the link to. Anybody with the link has access to the app.
We have had multiple instances where an employee of a company has access to the app and then that person leaves the company. At this point, the company requests us to disable access and there is no way to do this.
If the link is ever placed on a publicly accessible site, it may be crawled by a search engine. And the content of the app (the data shown in the app) could also be indexed by the search engine. This is because the intent for Publisher apps is to have broad public access to the app.
2. Can slices be used instead of a security filter?
Slices are a mechanism used to define "virtual tables". Even if somehow the user was identified and used in the filter condition of a Slice, this doesn't guarantee that the entire data set isn't accessible as well.
When the app is opened in a browser, all of the data used by the app is accessible to anyone who spends a couple of minutes to open the developer console and examine the data of the running application. There is no guarantee that the entire table isn't available even if a slice is defined on that table. The only way to ensure this is to use a security filter for the table.
3. Can I create my own username/password mechanism?
Not really. If you want to implement your own security, you need to worry about authentication (is the person who they claim they are), and a secure implementation (encrypted capture, transmission, and storage of passwords, as well as mechanisms to handle forgotten passwords, revocation, etc). This is a huge and complex undertaking. In fact, this is why AppSheet does not provide its own username and password mechanism. Instead, we utilize third party authentication via highly credible providers like Google, Dropbox and Office365.
4. Can I verbally tell people to sign-in and use expressions with USEREMAIL() to control app behavior?
No. USEREMAIL() and USERNAME() do not have a defined value if the app does not enforce user sign-in. The Login option in the app menu will also only be visible for apps that require sign-in. Apps should either assume all users are signed in, or assume that no users are signed in.
Alternatives to requiring sign-in
For reasons of cost, some app creators may want to stay with a Publisher Pro plan. We want to emphasize that these apps are inherently insecure. However, if the main goal is to acquire the user's email address rather than data/app security, here are some aspects of the functionality that can still be achieved:
In forms, instead of using USEREMAIL() to automatically fill in a column value, the user can explicitly type in their email address. This will not be verified, but an email can still be captured and used.
The app can utilize the UserSettings feature to ask the user to provide their email address. The benefit of this approach is that the email address is typed in once and then can be used in formulas (eg: UserSettings("MyEmail") ). This email is not authenticated (any user could claim to be email@example.com), so this is not a security mechanism.
If you have a fixed list of users in a Lookup table, you could assign each user an id and ask them to provide their id via the UserSettings feature. This id can be used with the Lookup table. Please note that this is not a password. It is not encrypted and all users will have access to the Lookup table, so this approach is in some ways even less secure than the other options.