Ensuring security and privacy in apps and for data is as important as building app features.
To secure apps and data, consider these security measures:
|App projects||Use App Maker to build app projects. An app project defines all or most of the features in an app, and most of the security.|
|Apps||You can apply some security measures to both data and the UI.|
|Execution identity||Specify whether an app runs as the user or as the app developer.|
|Data||Secure data stored in App Maker models.|
|Server scripts||Secure server scripts that access data.|
Manage security on an ongoing basis
If an application or the data it manages changes, we recommend you:
- Revisit security.
- Adjust security regarding changes in the real-world jobs of individuals and groups.
Manage these security measures on an ongoing basis:
Which users can run each app deployment
Which users are members of the Admins role for an app deployment
Which users are members of developer-defined roles for an app deployment
Best practices for security
Manage sharing of app projects—Sharing app projects for development and for app publishing also shares access to data.
Choose the execution identity—Each app uses the execution identity of the developer (the app publisher) or the user. Which execution identity is appropriate for your app depends on how the app is used and on the G Suite data that the app should access.
(If necessary) Secure data—If your app contains sensitive, confidential, or private data, secure the data:
Use roles, server scripts, or both to secure operations on records and the ability to associate records in relations.
Use Owner access permissions to restrict data access to the owners of records.
Secure server scripts that access data. You can make server scripts private. Public server scripts must implement data security.
Don’t rely on client scripts for data security. Client scripts are inherently insecure. Script-based security must run on the server.
(If necessary) Secure the UI—If your app has static content that some users shouldn’t see, secure the UI. For example, you might want to hide administrative pages from users who aren’t administrators.
Secure pages to restrict the retrievability of pages to specific users.
Control the visibility of UI elements. For example, you could hide links that lead to pages for administrators from users who aren’t administrators.
Control who can manage app deployments—App ownership and sharing control who can manage app deployments. Owners of an app project can manage deployments of the app. Editors (users with whom the app project is shared with Can edit access) can publish deployments. Management of a deployment includes the ability to republish the deployment, edit the deployment’s settings (including the membership of roles), export data from the deployment, delete the deployment, and view server logs.
(Optional) Specify who can run an app deployment—Restrict which users can run an app.
Decide whether to use the Admins role—The built-in Admins role has unique characteristics. Consider whether to use the Admins role or to define your own administrative roles.
Manage the membership of roles—If an app uses role-based security, manage the membership of roles.
Manage data security implemented by server scripts—Ensure that server scripts that access data are private, or that they implement security measures.
Manage security on an ongoing basis—If an application or the data it manages changes, revisit security. Also adjust security regarding changes in the real-world roles and job tasks of individuals and groups.