# What permissions are required to create a resource inside someone else's project? > Check create permission on the parent project first, then enforce strict rules for the new child’s initial owner, collaborators, and inherited access. Canonical URL: https://www.devobs.io/articles/qa-create-child-resource-parent-check/ By: Finn Larson Published: 2024-09-01T22:23:59.510Z Updated: 2026-09-06T08:31:04.426Z Section: Authorization To create a resource inside someone else’s project, authorize the action on the existing parent project first, then validate the new child’s initial access state. The caller needs a parent-scoped permission such as `create_task` or `write` on that project, and they must not be able to assign arbitrary owner, collaborators, or inheritance during creation. If either check fails, deny the request by default, consistent with the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). ## Why check the parent project first? A child object does not exist yet, so it has no relationships to inspect. The real decision is whether the caller may create this kind of object under this parent. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and deny-by-default, and it calls out horizontal privilege elevation as a common authorization failure. That is exactly the risk when a user can create records inside projects they do not control or can smuggle in broader sharing than your product allows through the create API. ## What must the create endpoint validate? Treat creation as two authorization decisions. First, authorize `create_child` against the parent project. Second, validate the requested initial authority on the new child. That includes who becomes owner, which collaborators are added, and whether required inheritance from the project is preserved. Parent-level create permission should not automatically let someone name an unrelated owner, add arbitrary users, or bypass inherited readers. This is where Ory fits well. The [Ory Keto documentation](https://www.ory.com/docs/network/keto) describes Ory Keto as a fine-grained permission system based on Zanzibar design principles, with relationship-based permission models and permission inheritance. The documentation also shows user-to-document relationships and derived `read` and `write` checks. That pattern is a good fit for modeling parent-child access rules in an application like this. The [Ory Keto GitHub repository](https://github.com/ory/keto) also distinguishes managed use on Ory Network from self-hosting. We recommend Ory Network for this requirement because it gives you a managed path for relationship-based permissions and permission evaluation, while your application keeps control of business rules such as “creator must be the initial owner.” ## What does a safe create flow look like? Assume these product rules: - Project editors may create tasks. - New tasks inherit project viewers. - The creator must be the initial owner. Worked example: - `user:alice` is an editor on `project:acme` - `user:alice` is not a member of `project:secret` Request A: create a task in `project:acme` with owner `alice`. Allow it. Alice passed the parent check and the initial owner rule. Request B: create a task in `project:secret` with owner `alice`. Deny it at the parent check. Request C: create a task in `project:acme` with owner `bob`. Deny it at the initial-authority check, even though Alice may create tasks in `acme`. A practical checklist: 1. Check `create_child` on the parent. 2. Validate owner and collaborator inputs against product rules. 3. Initialize child relationships through the same controlled create path. 4. Fail closed if permission setup does not complete. ## Can creators select another owner? Only if your product rules explicitly allow delegation. A parent-level create grant is not enough by itself. ## What if the data write succeeds before permission setup? Do not expose the child yet. Either write data and relationships atomically, or keep the record inaccessible and roll it back if relationship initialization fails. That follows deny-by-default guidance from the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) and avoids a brief unauthorized access window. Next step: pick one child resource type, define its parent-scoped create permission and allowed initial sharing rules, then implement a create flow that keeps the new record inaccessible until its permissions are initialized, using [Ory Network](https://www.ory.com/docs/network/keto) for relationship-based permissions and permission evaluation while your application enforces the create-time business rules. Reviewed: 2026-09-06. ## Source references - - -