Default application roles cannot express a field allowlist, undermining least-privilege app design

[remihuigen]

Summary

defineApplicationRole() does not provide a way to grant an app access to only a selected set of fields on an object.

Instead, field permissions appear to behave as deny-list overrides of an object-level baseline:

• An object permission is required before the app can access that object’s records.
• Once object read/update access is granted, every unspecified field is readable/updatable.
• Setting canReadFieldValue: true / canUpdateFieldValue: true for selected fields does not create an allowlist.
• To restrict the app to only three fields, I would need to add explicit false permissions for every other existing field.

This is both surprising and poor DX for application roles, where least privilege should be the default and easy to maintain.

Version

• twenty-sdk: 2.23.0
• twenty-client-sdk: 2.23.0
• twenty-server: 2.24.1

Reproduction

I defined a default application role intended to allow read/write access to Company records, but only to address, companyLatitude, and companyLongitude:

import {
  defineApplicationRole,
  STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS,
} from 'twenty-sdk/define'

export default defineApplicationRole({
  universalIdentifier: '...',
  label: 'Restricted app role',
  description: 'Should access only three Company fields',
  canReadAllObjectRecords: false,
  canUpdateAllObjectRecords: false,
  canSoftDeleteAllObjectRecords: false,
  canDestroyAllObjectRecords: false,
  canUpdateAllSettings: false,
  canBeAssignedToAgents: false,
  canBeAssignedToUsers: false,
  canBeAssignedToApiKeys: false,

  objectPermissions: [
    {
      objectUniversalIdentifier:
        STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.company.universalIdentifier,
      canReadObjectRecords: true,
      canUpdateObjectRecords: true,
      canSoftDeleteObjectRecords: false,
      canDestroyObjectRecords: false,
    },
  ],

  fieldPermissions: [
    {
      objectUniversalIdentifier:
        STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.company.universalIdentifier,
      fieldUniversalIdentifier:
        STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.company.fields.address
          .universalIdentifier,
      canReadFieldValue: true,
      canUpdateFieldValue: true,
    },
    {
      objectUniversalIdentifier:
        STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.company.universalIdentifier,
      fieldUniversalIdentifier: 'companyLatitude universal identifier',
      canReadFieldValue: true,
      canUpdateFieldValue: true,
    },
    {
      objectUniversalIdentifier:
        STANDARD_OBJECT_UNIVERSAL_IDENTIFIERS.company.universalIdentifier,
      fieldUniversalIdentifier: 'companyLongitude universal identifier',
      canReadFieldValue: true,
      canUpdateFieldValue: true,
    },
  ],

  permissionFlagUniversalIdentifiers: [],
})

I tested this using both:

1. The core API client in an app logic function.
2. An app front component.

Actual behavior

The app can read and update all Company fields.

If I remove the objectPermissions entry and retain the fieldPermissions, the app cannot access Company records at all.

The apparent workaround is to enumerate every Company field that must not be accessible and set both values to false, which is cumbersome and, in some cases, not even possible—for example, when an app is not aware of the full server schema.

Expected behavior

There should be a supported way to express:

This app may read/update Company records, but it may only read/update these named fields.

For example, one of:

• An allowlist mode for field permissions.
• Default-deny field access when an application role declares field permissions for an object.
• An explicit object-permission option such as defaultFieldAccess: 'none'.
• Separate application-role semantics that are secure-by-default, while retaining current behavior for user-assigned roles.

Why this matters: least privilege and DX

The current model creates a bad developer experience and makes least-privilege configurations fragile.

An app author must:

1. Grant object-level record access, because field permissions alone do not permit record access.
2. Discover and enumerate every other field on the object.
3. Add an explicit false permission for each one.
4. Repeat that work whenever Twenty adds a standard field, the workspace adds a custom field, or another app extends the object.

That is error-prone and does not remain least-privilege over time: newly added fields are accessible by default unless the app is updated to deny them.

The app-role documentation says the app token and typed API client are restricted to the role’s permissions, and recommends declaring only the permissions functions need. That wording reasonably suggests that declaring three field permissions should grant access to those three fields—not grant broad access to every unlisted field.

For application code handling potentially sensitive CRM data, a field allowlist is the safer and more natural declaration.

Evidence

The documentation describes defineApplicationRole() as controlling access for app logic functions and front components, and recommends least privilege:

https://docs.twenty.com/developers/extend/apps/config/application#default-function-role

The permissions FAQ describes field permissions as overrides of object-level permissions:

https://docs.twenty.com/user-guide/permissions-access/how-tos/permissions-faq#how-do-permission-overrides-work

The current implementation is consistent with deny-list semantics, but that leaves no future-safe allowlist mechanism for app roles.

Request

Please consider adding a field allowlist/default-deny option for defineApplicationRole() (or changing its field-permission semantics), and clarify the documentation in the meantime.

[sonarly]

🟠 Sonarly Analysis — High Severity

Field permissions are deny-only for application roles

Application roles cannot safely restrict an object to an explicit field allowlist. When object access is granted, unspecified fields remain readable and writable unless each one is explicitly denied.

Root Cause

The proximate cause is a contract mismatch between application-role declarations and the server's field-permission model.

defineApplicationRole() adds no application-specific permission semantics; it is exactly an alias for defineRole(config) (packages/twenty-sdk/src/sdk/define/roles/define-application-role.ts:5-6). The shared manifest type permits canReadFieldValue and canUpdateFieldValue to be either true or false, but it has no allowlist/default-deny option (packages/twenty-shared/src/application/roleManifestType.ts:11-16).

During manifest synchronization, the application manifest values are copied directly into flat field-permission metadata, including true values (packages/twenty-server/src/engine/core-modules/application/application-manifest/converters/from-field-permission-manifest-to-universal-flat-field-permission.util.ts:15-24). The manifest migration then registers those entries without passing through the normal user-role field-permission upsert validation (packages/twenty-server/src/engine/core-modules/application/application-manifest/utils/compute-application-manifest-all-universal-flat-entity-maps.util.ts:287-297).

At runtime, the role cache stores declared field entries as restrictedFields (packages/twenty-server/src/engine/metadata-modules/role/services/workspace-roles-permissions-cache.service.ts:208-229), but the ORM permission checks only deny when a field's value is explicitly false:

if (restrictedFields[fieldMetadataId]?.canRead === false) {
  throw new PermissionsException(...);
}

if (restrictedFields[fieldMetadataId]?.canUpdate === false) {
  throw new PermissionsException(...);
}

(packages/twenty-server/src/engine/twenty-orm/repository/permissions.utils.ts:411-441 and :453-472.) A declared true value therefore does not create an allowlist, and an undeclared field has no restricted-field entry at all. Both cases remain permitted after object-level access is granted.

Object and field access are also separate. The cache computes canReadObjectRecords and canUpdateObjectRecords independently from restrictedFields (packages/twenty-server/src/engine/metadata-modules/role/services/workspace-roles-permissions-cache.service.ts:232-235). This explains both reproduction results: field declarations alone cannot grant record access, while an object permission enables record access and leaves all unspecified fields available.

The deny-only behavior is intentional in the existing permissions subsystem, not an accidental exception. The normal field-permission service rejects positive values with ONLY_FIELD_RESTRICTION_ALLOWED and explicitly tells users that field permissions can restrict access but cannot grant it (packages/twenty-server/src/engine/metadata-modules/object-permission/field-permission/field-permission.service.ts:337-349). Integration tests also intentionally cover positive values as invalid inputs. However, application manifests accept those same values and give app authors no way to request a distinct allowlist mode. The application-role documentation simultaneously recommends replacing permissions with the exact objects and fields functions need (packages/twenty-docs/developers/extend/apps/config/roles.mdx:89-94), which makes the application API contract misleading.

The triggering cause for this report was the deployed application role configuration described in the issue: the app set company object read/update permissions to true, declared only three company fields with positive field values, and then accessed company records through the application API client and front component. That declaration activated the existing object baseline plus deny-only field evaluation. The repository evidence does not establish the exact installation/deployment timestamp, whether a later schema change triggered the report, or how many applications or workspaces are affected; no production observability data was provided.

Blame commit: ae6adb3a by ijreilly — [permissions] Add read field permission check layer (part 1) (#13376)

Suggested Fix

Updated the role-permission cache to recognize positive field permissions as application field allowlists. When an object has positive read or update field permissions, every field on that object is initialized as denied for the corresponding operation, then explicitly declared permissions override those defaults. This preserves the existing deny-only permission enforcement while ensuring undeclared and newly added fields are not exposed or writable.

The cache now loads field metadata and the role module registers the repository dependency. Existing permission consumers continue to enforce the generated false restrictions without requiring changes to their interfaces. Added a regression test verifying that declared fields remain allowed while unspecified fields are denied for both read and update operations.

---

Analyzed by Sonarly · View full analysis

[remihuigen]

After giving this some more thought, I think this issue is broader than just the default application role. The same concerns apply to every role—whether it's an agent, a user, or an app.

The current design is effectively most permissive by default. You have to actively restrict a role's permissions.

I think a better design would be to make least permissive the default instead. In other words, a default role (with empty permission arrays and the global "canCrudAll" flags set to "false") should have no permissions.

That would allow builders to incrementally grant permissions to a role, without ever unintentionally over-sharing capabilities.