Skip to main content

Command Palette

Search for a command to run...

Cloning a record can copy share grants the cloner could never create

Updated
•2 min read•View as Markdown
A
Practical lessons on auth, authorization, and access control.

Clone and duplicate endpoints often copy the source row, then copy its ACL or share table in the same transaction. The share dialog already stops that user from adding certain people or roles, but the clone path skips the check because it treats inheritance as a data copy.

Maya can read Project Alpha and create projects in the workspace, but she cannot share outside her team. When she clicks Duplicate, the new project still lists Alex (an external contractor) as editor, taken straight from Alpha's share rows. Maya could not have added Alex through Share, yet the clone did it for her.

When you clone a record, do not copy share or ACL rows blindly. Recreate a grant only when the acting user could create that same grant on a new record today. Drop anything they could not grant. Ownership of the clone should land on the cloner (or whatever default your product defines), not on whoever owned the source.

Quick test: as a user who can read and duplicate but cannot share externally, duplicate a record that already has an external editor. The clone must not list that external editor unless your product asks and the cloner confirms a grant they are allowed to make.