Skip to content

feat(secrets): allow admins to view and edit workspace secret values#4040

Merged
waleedlatif1 merged 2 commits intostagingfrom
waleedlatif1/editable-workspace-secrets
Apr 8, 2026
Merged

feat(secrets): allow admins to view and edit workspace secret values#4040
waleedlatif1 merged 2 commits intostagingfrom
waleedlatif1/editable-workspace-secrets

Conversation

@waleedlatif1
Copy link
Copy Markdown
Collaborator

@waleedlatif1 waleedlatif1 commented Apr 8, 2026

Summary

  • Admins can now reveal, edit, rename, and delete workspace secret values (previously read-only for everyone)
  • Non-admins see masked values with no edit/delete controls
  • New workspace secrets can only be created by admins
  • Permission check derived from workspace permissions query

Type of Change

  • New feature

Testing

Tested manually

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

@vercel
Copy link
Copy Markdown

vercel bot commented Apr 8, 2026 •
edited
Loading

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Apr 8, 2026 6:27am

Request Review

@cursor
Copy link
Copy Markdown

cursor bot commented Apr 8, 2026 •
edited
Loading

PR Summary

Medium Risk
Changes access/visibility controls for secret values in the settings UI; mistakes in permission checks could unintentionally expose or allow edits, so verify server-side enforcement matches the new client behavior.

Overview
Workspace secrets UI is now permission-aware: workspace admins can reveal/edit secret values, rename keys, delete entries, and add new workspace secrets, while non-admins see masked values and no destructive/create controls.

This derives isWorkspaceAdmin from useWorkspacePermissionsQuery and threads a canEdit flag through WorkspaceVariableRow, adding inline value editing via onValueChange and tightening input focus behavior so read-only fields only become editable for admins.

Reviewed by Cursor Bugbot for commit 72d4e72. Configure here.

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Apr 8, 2026 •
edited
Loading

Greptile Summary

This PR adds workspace-admin permission gating to the workspace secrets management UI, allowing admins to reveal, rename, edit, and delete workspace secrets while non-admins see only masked values and no edit/delete controls. The isWorkspaceAdmin flag is derived client-side from useWorkspacePermissionsQuery.

Key findings:

  • The server-side GET /api/workspaces/[id]/environment returns fully decrypted values to all workspace members, not just admins. Non-admin masking is purely cosmetic.
  • Admin masking uses WebkitTextSecurity: 'disc' which has no effect in Firefox.
  • Client gates edits on permissionType === 'admin' but the API allows admin or write users.

Confidence Score: 3/5

Not safe to merge as-is — the non-admin value masking is purely cosmetic because the server returns decrypted secrets to all workspace members.

The P1 finding directly contradicts the PR's stated goal of restricting secret visibility to admins. The API write-path is correctly protected, so there is no data-corruption risk, but the confidentiality guarantee is broken.

Both credentials-manager.tsx and apps/sim/app/api/workspaces/[id]/environment/route.ts need attention.

Vulnerabilities
  • Secret value exposure to non-admins: The GET endpoint returns fully decrypted workspace environment variable values to any workspace member regardless of role, bypassing the frontend masking.
  • Inline style masking: WebkitTextSecurity: 'disc' is ineffective in Firefox for admin users.

Important Files Changed

Filename Overview
apps/sim/app/workspace/[workspaceId]/settings/components/credentials/credentials-manager.tsx Adds workspace-admin permission gating to secret editing UI; non-admin masking is cosmetic only since the backend GET returns decrypted values to all members.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant Frontend as CredentialsManager
    participant PermAPI as GET /workspaces/[id]/permissions
    participant EnvAPI as GET /workspaces/[id]/environment

    Browser->>Frontend: Page load
    Frontend->>PermAPI: useWorkspacePermissionsQuery
    PermAPI-->>Frontend: users with permissionType
    Frontend->>EnvAPI: useWorkspaceEnvironment
    EnvAPI-->>Frontend: DECRYPTED_VALUES for all members
    Note over Frontend: isWorkspaceAdmin = permissionType === admin

    alt Admin user
        Frontend->>Browser: Editable inputs plus delete buttons
        Note over Browser: Masked until focused (WebKit only)
    else Non-admin user
        Frontend->>Browser: Read-only inputs, no delete buttons
        Note over Browser: Cosmetic masking only, values in network response
    end
Loading

Comments Outside Diff (2)

  1. apps/sim/app/workspace/[workspaceId]/settings/components/credentials/credentials-manager.tsx, line 329-334 (link)

    P1 security Server-side data leaks workspace secrets to non-admins

    isWorkspaceAdmin correctly restricts the editing UI to workspace admins, but the backend GET /api/workspaces/[id]/environment returns fully decrypted workspace variables to every workspace member (any permissionType). The workspaceVars state is therefore populated with plaintext secret values for non-admins too — the bullet-character masking at line 179 is purely cosmetic. Any non-admin can read the actual values by:

    1. Opening DevTools → Network → inspecting the GET .../environment response
    2. Querying the TanStack Query cache in the browser console

    If the intent is to truly restrict secret visibility to admins, the GET handler needs to either return masked values or only return the full set to admin-permissioned users.

  2. apps/sim/app/workspace/[workspaceId]/settings/components/credentials/credentials-manager.tsx, line 329-334 (link)

    P2 Client-side admin check is more restrictive than the server

    isWorkspaceAdmin requires permissionType === 'admin', but the PUT and DELETE handlers in apps/sim/app/api/workspaces/[id]/environment/route.ts (lines 88 and 174) allow admin OR write users to mutate workspace environment variables. This means a user with write permission is silently blocked by the UI even though the API would accept their request.

    If the intent is to limit workspace-secret editing to admin only, the server-side check should also be tightened to match.

Reviews (1): Last reviewed commit: "feat(secrets): allow admins to view and ..." | Re-trigger Greptile

@waleedlatif1
Copy link
Copy Markdown
Collaborator Author

waleedlatif1 commented Apr 8, 2026

@greptile

@waleedlatif1
Copy link
Copy Markdown
Collaborator Author

waleedlatif1 commented Apr 8, 2026

@cursor review

cursor[bot]
cursor bot reviewed Apr 8, 2026
View reviewed changes
Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 72d4e72. Configure here.

@waleedlatif1 waleedlatif1 merged commit 9282d1b into staging Apr 8, 2026
12 checks passed
@waleedlatif1 waleedlatif1 deleted the waleedlatif1/editable-workspace-secrets branch April 8, 2026 06:40
@waleedlatif1 waleedlatif1 mentioned this pull request Apr 8, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@greptile-apps greptile-apps[bot] greptile-apps[bot] left review comments

@cursor cursor[bot] cursor[bot] left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@waleedlatif1