Summary
Tandoor Recipes improperly authorizes access to private recipe steps and ingredients when requests come from authenticated users in the same Space. A user with read and write API scope may read or silently modify another member's private recipe by supplying its identifier, while cross-Space access is generally outside the described scope.
Tandoor Recipes improperly authorizes access to private recipe steps and ingredients when requests come from authenticated users in the same Space. A user with read and write API scope may read or silently modify another member's private recipe by supplying its identifier, while cross-Space access is generally outside the described scope.
Affected context
The issue occurs in Tandoor Recipes API endpoints handled by StepViewSet and IngredientViewSet, including step collection and detail routes. It requires a shared Space, an authenticated account with suitable read and write API scope, and a private recipe or step belonging to another member of that Space. Cross-Space access is not indicated as affected.
The issue occurs in Tandoor Recipes API endpoints handled by StepViewSet and IngredientViewSet, including step collection and detail routes. It requires a shared Space, an authenticated account with suitable read and write API scope, and a private recipe or step belonging to another member of that Space. Cross-Space access is not indicated as affected.
Exploit preconditions
- Attack surface: Tandoor Recipes API sub-resource endpoints for steps and ingredients
- Required access: An authenticated user with read and write API scope in the victim's Space
- Trigger point: Supplying another member's private recipe or step identifier to the relevant API request
- Why exploitation is possible: The sub-resource querysets filter by active Space membership but do not consistently enforce private-recipe ownership or sharing authorization
- Attack surface: Tandoor Recipes API sub-resource endpoints for steps and ingredients
- Required access: An authenticated user with read and write API scope in the victim's Space
- Trigger point: Supplying another member's private recipe or step identifier to the relevant API request
- Why exploitation is possible: The sub-resource querysets filter by active Space membership but do not consistently enforce private-recipe ownership or sharing authorization
Why this happens
The authorization logic relies on Space membership and role-level CustomIsUser checks instead of applying the private-recipe owner or sharing predicate to sub-resource queries and updates. As a result, object identifiers can select private recipe steps belonging to another same-Space member, mapping to CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, and CWE-863 Incorrect Authorization.
The authorization logic relies on Space membership and role-level CustomIsUser checks instead of applying the private-recipe owner or sharing predicate to sub-resource queries and updates. As a result, object identifiers can select private recipe steps belonging to another same-Space member, mapping to CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, and CWE-863 Incorrect Authorization.
Potential impact
- An attacker may read private recipe instructions
- An attacker may silently modify another user's private recipe steps
- Recipe confidentiality and integrity could be weakened within a shared Space
- Modified instructions could cause planning, preparation, or collaboration errors
- Unauthorized changes could undermine trust in shared recipe data
- An attacker may read private recipe instructions
- An attacker may silently modify another user's private recipe steps
- Recipe confidentiality and integrity could be weakened within a shared Space
- Modified instructions could cause planning, preparation, or collaboration errors
- Unauthorized changes could undermine trust in shared recipe data
General mitigation guidance
Mitigation should center on enforcing authorization at the object and sub-resource level rather than relying only on container or Space membership.
Defensive patterns include:
- Apply private-recipe ownership and sharing predicates consistently to read and write querysets
- Reuse centralized, deny-by-default permission checks for every object access path
- Treat user-supplied identifiers as selectors only after authorization has been evaluated
- Keep read and write authorization rules explicit and independently verified
- Limit API scopes and Space roles to the minimum required privileges
- Use consistent authorization behavior for collection, detail, and nested-resource endpoints
Mitigation should center on enforcing authorization at the object and sub-resource level rather than relying only on container or Space membership.
Defensive patterns include:
- Apply private-recipe ownership and sharing predicates consistently to read and write querysets
- Reuse centralized, deny-by-default permission checks for every object access path
- Treat user-supplied identifiers as selectors only after authorization has been evaluated
- Keep read and write authorization rules explicit and independently verified
- Limit API scopes and Space roles to the minimum required privileges
- Use consistent authorization behavior for collection, detail, and nested-resource endpoints
How teams detect issues like this
Detection can include:
- Static analysis for queryset filters that use tenant or Space membership without object-owner or sharing constraints
- Code review checks comparing collection and detail endpoint authorization behavior
- Tests that attempt same-Space access to private objects owned by another user
- Policy checks requiring authorization before object retrieval, serialization, and update operations
- Monitoring for unusual access to private recipe identifiers or unexpected update activity
- Automated security review tools that identify insecure direct object reference and missing authorization patterns
Detection can include:
- Static analysis for queryset filters that use tenant or Space membership without object-owner or sharing constraints
- Code review checks comparing collection and detail endpoint authorization behavior
- Tests that attempt same-Space access to private objects owned by another user
- Policy checks requiring authorization before object retrieval, serialization, and update operations
- Monitoring for unusual access to private recipe identifiers or unexpected update activity
- Automated security review tools that identify insecure direct object reference and missing authorization patterns
