As needed, secure your app projects, app deployments, and app data to ensure that security and privacy requirements for your apps are met.
Also consider the execution identity of apps—whether apps run as the user or the developer.
Secure app projects
An app project is the app that you develop, share, and deploy in App Maker. An app project describes how an app is constructed. An app project also contains all of the data in Google Drive Tables data models, in all of the deployments of an app.
Consider who owns app projects
Every app project has an owner—initially the person who creates the project. Ownership of an app project is transferable.
- Project owners are powerful—A project owner has full control over the app project and app deployments. A project owner also has full access to the data in all deployments of the app, even if the project or deployments restrict the owner from having that access (because the project owner can give themself access).
- Transfer ownership of an app project—In some cases, it might be appropriate to transfer ownership; for example, if someone leaves the company or if responsibilities change. Transferring ownership also might be appropriate when transitioning from development to operations.
You can share app projects with specific users (Google Accounts) and groups (Google groups). Sharing works the same way that it works for Drive, Docs, and Sheets. These are the access levels for sharing a project.
- Can edit—Users with whom an app project is shared with Can edit access can develop the app and publish app deployments. They also have full access to all data in all deployments of the app.
- Can view—Sharing with Can view access gives read-only access to the app project. It doesn’t give the ability to preview apps or to publish app deployments. It gives read access to all data in all deployments of the app.
Deployment actions and project sharing
This table summarizes how project sharing affects deployment actions:
|Action||Owner||Editor and deployer||Editor||Viewer|
|View a list of deployments|
|Publish a deployment|
|Edit a deployment|
|Republish a deployment|
|Delete a deployment|
- Consider whether and with whom to share an app project—An app project describes how an app is built. It also contains all of the data in Google Drive Tables data models, in all app deployments.
- Don’t share your app project with someone unless you fully trust that person—An app editor can change the app, permissions, and scripts. An app editor can change what data is accessed, who can access the data, and what access permissions people have.
Transfer the ownership of app projects
An owner of an app project can transfer ownership of the app project to someone else. A G Suite administrator can also transfer ownership.
Export, share, and import app project files
You can export app projects into files. You can share and import app project files.
What is an app project file?
An app project file is a complete record of how an app is constructed. It contains data models, the user interface, and scripts. It includes information about roles, but not the membership of the roles (which is defined in deployments). If the app uses Google Cloud SQL, the app project file contains the instance name.
An app project file doesn’t contain app data (which is in deployments). An app project file doesn’t present as many possible security concerns as a shared app project.
What can a developer do with an app project file?
A developer can import an app project file, which creates a new app. The developer could use this app to publish app deployments that are visually and functionally identical to app deployments published from the original app project.
- Only share app project files with those you trust.
- Only import app projects from those you trust.
- Make sure you understand what you import—App projects define some aspects of app security and how to access data.
Securing apps is a core part of security.
Run an app as the user or developer
App Maker uses a specific account when it runs the server part of an app—the app user’s account or the account of the developer who publishes the app. App Maker uses the account when the app runs server scripts and when it makes API calls to Google Apps Script Services (G Suite Services, Script Services, and Advanced Google Services).
Use the built-in Admins role
The built-in Admins role differs from roles that you can create:
|Aspect||Admins role||Other roles|
You add other roles in the app project.
|Default data security when you create a model||
App Maker sets model permissions for all operations on records to Admins Only.
This default also applies for associating records (through the Inherited access permission).
Model permissions remain Admins Only until you set up different model permissions.
You can change the access permission to Roles and add other roles.
|Default page security||
The default access permission is Everyone.
|Add role-based security to models, relations, and pages
(in the App Maker model and page editors)
|Add role-based security to models, relations, and pages
(in scripts and binding expressions)
|Useful for job-role and job-task administrators
(for example, administrators in different departments who have different job tasks)
|Possibly, but only if the different administrators should access all app features and data in the same way|
|Preview an app||App Maker adds you to the Admins role.
Previews only have the Admins role and the app owner is the only member of that role.
To test permissions, you must publish a deployment of your application and specify role membership.
|Publish an app||The first time you publish a deployment of an app, App Maker adds the publisher of the app to the Admins role.
You can change the membership of the Admins role while publishing a deployment or afterward.
|You can specify the membership of other roles while publishing the deployment or afterward.|
Define and use roles
Roles are sets of users that you can use to implement role-based access control. The sets can include individual Google Accounts and Google Groups.
You can use roles:
- To specify which users can access the app deployment’s data. See Secure data for more information.
- To specify which sets of people can access specific pages and view specific UI elements. See [Secure the UI]/appmaker/security/secure-the-ui) for more information.
- To control access to data through server scripts. Roles are one of three approaches for using access permissions to control user access. The other approaches are Script permissions and Owner permissions. If you don’t use role permissions, you don’t need to add roles.
- Open App Maker and navigate to your app project.
- Click Settings App settings.
- Under Security Access Roles, enter role names.
How to use roles
Define roles and add users and groups to them based on:
- Job roles
- Which tasks people in your organization can perform
- Which data people in your organization should have access to
For example, as an employee, you might edit your contact information. As a manager, you might approve vacation requests. As a member of the Finance department, you might view accounts receivable and accounts payable.
You create roles in the app project, but specify their members in app deployments. This lets you publish multiple versions of your app, for example testing and production versions, with different role memberships. You can modify role membership for a published app without republishing the app.
To use roles to control app security:
- Decide which roles make sense for your app, based on job roles, tasks that people perform, and requirements regarding data access.
- Add roles.
- Secure operations on records.
- Secure relations between models.
- Secure pages.
- Secure server scripts.
- (Optional) Control the visibility of UI elements.
- Publish your app and add members to roles.
Set access permissions
You must set access permissions to give specific users access to specific data and to specific parts of an app’s UI.
You can set access permissions to control:
- The data users can access and the types of access they have
- The pages users can view
- The visibility of widgets (for example, a link from a user page to a page for managers could test for the Managers role)
Where you can apply access permissions
- Record access for a data model, for Create, Load, Save, and Delete operations. By checking the Advanced box, you can set access permissions for Create, Load, Save, and Delete operations separately. By unchecking the Advanced box, you can set the access permission for all operations.
- Ability to associate records in the data models (or model) on both ends of a relation
- Access to a page in the app’s UI
Access permission types
Access permissions give specific users who can run an app access to specific data and to specific pages in an app’s UI. You can limit who can run an app under Application access in the settings for a deployment.
Except as noted, you can choose among all of these access permissions for record operations (Create, Load, Save, and Delete), for relations (specifically for associating records governed by relations), and for pages.
|Admins Only||Only users who are added to the Admins role in an app’s deployment settings have access.
When you create a data model, App Maker uses Admins Only as the default permission for record operations and relations. This provides some data security until you implement the data security that is appropriate for your app.
|Everyone||If everyone on a domain can run the app, then everyone has access. Otherwise, only users who can run the app deployment have access. Specify who can run the app under Application access in the settings for a deployment.|
|Roles||Only members of the specified roles have access. You add roles in an app project. You add users to the roles in an app’s deployment settings.|
|Script||Only users that are given access by a server authorization script have access. You write the script in a script editor that appears when you choose this access permission type.|
|Owner or Roles||For record operations, only owners of records or members of the specified roles have access. App Maker decides whether a user is the owner of a record by matching the user’s email address with the contents of a field in the record. You specify which field to use.|
|Inherited||For relations, users who can save records in the data models on both ends of the relation can associate records.|
You can use more than one permission type in an app, and even for separate instances of the same type of thing. For example, a data model that contains data that can be widely known could use Everyone permission for all record operations, while a data model in the same app that contains personally identifiable information could use Roles or Script permissions.
Use default access permissions
When you create these parts of an app, App Maker gives them default permissions:
- Models—Admins Only. Restricts access to data in Google Drive Tables to members of the Admins role.
- Relations—Inherited. Restricts the ability to associate records governed by the relation to users who can save records in the data models (or model) on both ends of the relation.
- Pages—Everyone. Everyone can view the page.
Examples of access permissions
Templates and samples use access permissions:
Access based on record ownership—The Forum Sample lets users create forums and post messages to the forums. A user who creates a forum is the owner of that forum. The
onCreateevent for a record in the Forum data model sets the value of the Owner field in the record to the user’s email address. Owner access permissions for the Save and Delete actions specify that only the owner can edit the forum or delete it.
Page for administrators—The Starter App and Material Gallery templates have a page called Admin. The page uses Admins Only permission to restrict access to the page to members of the Admins role. Role membership is defined by editing deployments.
As a core part of app security, you can secure data for all apps, even if some apps don’t contain sensitive or confidential data; for example personally identifiable information (PII).
Use these security measures to secure data
Run the app as the user or as the developer (the person who publishes an app deployment)—Choose the appropriate execution identity for the app’s use case, which determines:
Which files in Google Drive users can access—the app publisher’s files and data, or their own files and data
Which G Suite data users can access—the app publisher’s files and data, or their own files and data
The identity for API calls to Google Apps Script services; for example, to send mail and make entries in a calendar
Secure operations on records in models—Use Roles, Script, and Owner access permissions for operations on records (Create, Save, Load, and Delete). This allows specific users to perform specific types of operations on records in models. You can use one access permission type for all types of operations on records, or different access permission types.
Secure relations between models—Use Inherited, Roles, or Script access permissions for relations (or some combination). This allows specific users to associate records on both ends of the relations.
- Don’t rely on UI security for data security—UI security measures (page security and controlling the visibility of UI elements) do not secure data. UI security only controls who can do what through the UI.
- Don’t use client scripts or an application startup script for data security—Client scripts are inherently insecure. Script-based security must run on the server. Find more information and procedures for securing data here.
Secure the UI
As a part of app security, you can secure pages and UI elements—widgets or parts of widgets. Security for the UI determines whether a user can see something (or hear it with a screen reader).
Using App Maker, you can use one or both of these approaches to secure your app’s UI:
- Secure pages—Use page security to control which pages users can see. In the Property Editor , under Security, apply Roles or Script access permissions to each page.
- Secure UI elements—Use the
visibleproperty to control which elements on a page users can see. The visible property is available for widgets and for parts of compound widgets. In the Property Editor , under Display, define a binding expression for the UI element that resolves to
Find more information and procedures for securing the UI here.
Secure server scripts
If your app accesses sensitive data, you must secure server scripts. For example, a server script could ensure that the user for which data is requested is the active user in the session. App Maker doesn’t automatically check access permissions when running server scripts.
Use one or both of these measures to secure server scripts:
- Hide server scripts—Any function you define in a server script is available for all users of an app, even if you don't call the function from the UI. To write a utility function that can only be called from server scripts, append an underscore to the function name.
- Implement security in server scripts that aren't hidden—In server scripts that you don't hide, implement access permission checks.
App deployments are the apps that users run. App deployments inherit some security measures from app projects.
To secure deployments, you specify:
- Who can run the deployment
- Membership of the Admins role, and of other roles if Roles access permissions are used
- Consider who owns a deployment of an app—For a deployed app, only the app publisher is an owner of the deployment, not the app owner. An app owner can take ownership of a deployment.
- Ensure that you publish or republish the correct revision of an app—Tag app revisions so you know what revision is what.
- Thoroughly test an app before you publish it, and after you publish it—Testing should include running the app as different users with different permissions. It should also include bypassing UI security.
- Don’t delete a deployment—Deleting a deployment deletes the data that is managed by that deployment of the app, if the data is in Google Drive Tables.
Specify who can run an app deployment
By default, all users on your domain can run an app deployment.
You can create a whitelist of specific users who can run an app deployment (identified directly by Google Accounts or by groups through Google Groups). Users who can't run the app see a message that informs them that they don't have access to the app.
To allow specific users to run an app deployment:
- Open App Maker and navigate to your app project.
- Click Settings Deployments.
- On the row for the deployment, click Edit.
- Under Application access, select Only allow access to specific users.
- Enter the email addresses of specific users (Google Accounts), groups (Google Groups), or both.
- Click Save. App Maker automatically republishes the deployment.
Add members to roles
If you use Roles access permissions to secure data or pages, you must add members to the roles. Specify the email addresses of individuals (Google Accounts), groups (Google Groups), or both.
To add members to a role:
- Open App Maker and navigate to the app for which you want to export data from a deployment into a Google spreadsheet.
- Click Settings Deployments.
- In the table entry for the deployment for which you want to add members to a role, click Edit.
- Under the Users with role access sections, enter the email addresses of specific users (Google Accounts) or groups (Google Groups).
- Click Save. App Maker republishes the app deployment. The republished deployment has the changes in role membership.
Previews include these security features:
- Preview URLs are private—Only the developer who previews an app can see that preview. The URL for the preview doesn’t allow anyone else to run the preview deployment.
- Preview-resident data—Data in Google Drive Tables is in the preview. Multiple developers who preview a shared app project create different previews, each with its own data (or with no data if the developer hasn't added any data).
Publishing an app allows other users to run the app, subject to restrictions on who can run the app. What users can do in the app and what data users can see depend on which security measures the app developers add.
As a security precaution, in published apps for which data security has not been set up, the initial access permission for operations on records is Admins Only.
Take ownership of a deployment
If the owner of a deployment edits or republishes a deployment that an editor originally published, this takes ownership of the deployment.
If you stop sharing a project, you don’t affect deployments that were published by editors. In this case, you need to take ownership of any deployments that were published by editors.
Import and export data
App Maker allows the person who published a deployment to import data into the deployment and to export data from the deployment. Both of these actions might create security risks; for example, if the data includes sensitive or confidential data, such as personally identifiable information (PII):
- Importing data—Importing data from a Google spreadsheet into a model in a deployment of an App Maker app imports all of the data into the deployment. If the Google spreadsheet contains sensitive or confidential data, then the deployment of the app also contains that information.
- Exporting data—Exporting data from models in an App Maker app exports all of the data to a Google spreadsheet. If the model contains sensitive or confidential data, then the spreadsheet also contains that information.