Understand data security and visibility controls in Quickbase

Quickbase applications use a security model built on a system of roles and permissions. This system is great for controlling data access, especially when combined with thoughtful design. 

Use roles and permissions when it is inappropriate for a user to view confidential or sensitive information, or perform an action they should not be allowed to. For example, opening pay rates or editing an invoice after it's been paid. Use user interface (UI) controls, like form rules, to hide different pieces of information or screens as part of a workflow. This article explains roles, permissions, UI design, and examples. It is important to control data access, not just hide data.

Understand roles and permissions

In Quickbase, there are: 

• Roles—Create roles for different types of users, like project manager or client. Each user is assigned a role that controls their access.
• Permissions—Set permissions for each role, at different levels.
  • App-level permissions control access within an app. This includes managing users and editing the app structure.
  • Table-level permissions control access to view, modify, add, and delete records within a specific table. You can restrict access to all records, or only records that meet certain criteria, like only records they created.
  • Field-level permissions control access to fields in a table. Like table permissions, grant access to all fields, no fields, or define which fields someone can view and modify.

Understand UI design and control

Use UI hiding to declutter, not to secure. Rely on access rules to create real barriers and control data access. Customize the user interface, or how the app looks, for different roles. This means you can hide or show things like tables, reports, buttons, and links. You can also use form rules to dynamically hide or show things.

Best practice, direct security

Security through obscurity is the practice of relying on hiding information to protect it. In Quickbase, this means using UI controls as your primary method of security. We strongly recommend against this because it is dangerous and easier to make mistakes. For example, someone could accidentally expose things or forget to hide something, resulting in people viewing things they shouldn’t. 

Just because a user can't see a button or a link doesn't mean they can't access the underlying data. Hiding is for convenience, permissions are for security. 

When someone hides data instead of restricting it, it could still be accessed in different ways, including direct URL access or API calls. 

The only way to truly secure your data in Quickbase is by setting the correct permissions for each role. Hiding parts of the UI is a helpful way to streamline a user's experience, but it is not a security measure.

Our recommended best practice is: 

• Design for least privilege first, then use UI hide options for clarity.
• Test roles with the Test as role and Test as user features to confirm what a user sees.
• Audit regularly. Realm and app admins have access to audit logs. Use them to find unexpected access.
• Set the default access to new tables. Restrict access to new tables for specific roles. Learn more about setting this access.
• Restrict access to user tokens to mitigate API access. When someone has data access, they can use API calls to access data. That means that you might want to restrict access to user tokens to mitigate API access.Learn more about user tokens.

Examples

Use reports to hide sensitive data

• Bad practice: Relying on reports to hide sensitive information by simply not including certain fields.
• Why it fails: Users can create their own reports and access any reportable fields.
• Better alternative: Use role-based permissions to restrict access to sensitive fields at the field level.

Public access without controls

• Bad practice: Using Everyone on the internet to expose parts of a workflow to anonymous users, giving view or modify access to records that are hidden through reports, role user interface, form rules, and so on. Learn more about EOTI access.
• Why it fails: Exposes data to unauthorized users without authentication.
• Better alternative: Use secure links or custom role permissions. Learn more about secure links and custom role permissions.

Relying on form rules to hide data

• Bad practice: Depending on a form rule to hide data.
• Why It fails: Form rules only work when a user is on the form. They may be able to edit the data using other forms or by adding to a report, and then grid editing.
• Better alternative: Implement proper data access controls through roles and permissions.

More examples