Summary
Shaark contains a missing authorization vulnerability in the Link, Story, Chest, and Album API controllers. An authenticated non-admin user may use numeric resource identifiers in PUT or DELETE requests to overwrite or delete content owned by other users, including private items.
Shaark contains a missing authorization vulnerability in the Link, Story, Chest, and Album API controllers. An authenticated non-admin user may use numeric resource identifiers in PUT or DELETE requests to overwrite or delete content owned by other users, including private items.
Affected context
The issue affects Shaark deployments using the Link, Story, Chest, or Album API controllers in the affected 1.2.x release range. It becomes risky when these endpoints identify resources by numeric IDs but do not verify that the authenticated user owns the referenced resource or otherwise has permission to modify it.
The issue affects Shaark deployments using the Link, Story, Chest, or Album API controllers in the affected 1.2.x release range. It becomes risky when these endpoints identify resources by numeric IDs but do not verify that the authenticated user owns the referenced resource or otherwise has permission to modify it.
Exploit preconditions
- Attack surface: Authenticated HTTP PUT and DELETE endpoints under
/api/{link,story,chest,album}/{id} - Required access: A valid non-admin user account
- Trigger point: A request referencing another user's numeric resource identifier
- Why exploitation is possible: The controllers process the requested resource without consistently enforcing ownership or object-level authorization checks
- Attack surface: Authenticated HTTP PUT and DELETE endpoints under
/api/{link,story,chest,album}/{id} - Required access: A valid non-admin user account
- Trigger point: A request referencing another user's numeric resource identifier
- Why exploitation is possible: The controllers process the requested resource without consistently enforcing ownership or object-level authorization checks
Why this happens
The underlying bug is an object-level authorization failure. The API controllers rely on an authenticated session and a client-supplied numeric identifier but do not reliably confirm that the requested object belongs to the current user or is otherwise authorized for that user to change. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where access decisions are made without adequately binding the referenced object to the requester's permissions.
The underlying bug is an object-level authorization failure. The API controllers rely on an authenticated session and a client-supplied numeric identifier but do not reliably confirm that the requested object belongs to the current user or is otherwise authorized for that user to change. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where access decisions are made without adequately binding the referenced object to the requester's permissions.
Potential impact
- An authenticated user may overwrite content belonging to another user
- Private links, stories, chests, or albums may be deleted
- Content integrity and availability could be reduced
- Users may lose control over private or shared information
- Unauthorized changes could undermine application trust and moderation workflows
- An authenticated user may overwrite content belonging to another user
- Private links, stories, chests, or albums may be deleted
- Content integrity and availability could be reduced
- Users may lose control over private or shared information
- Unauthorized changes could undermine application trust and moderation workflows
General mitigation guidance
Mitigation typically focuses on enforcing object-level authorization at every resource-changing endpoint.
Common defensive patterns include:
- Check ownership or an explicitly granted permission before every update and deletion
- Centralize authorization decisions in reusable policy or service-layer functions
- Treat resource identifiers as untrusted input and resolve them within the current user's authorization scope
- Apply deny-by-default behavior for private and user-owned objects
- Use separate administrative authorization paths with explicit privilege checks
- Add regression tests covering cross-user access to all CRUD operations
- Avoid relying solely on client-side filtering, obscured identifiers, or authentication status
Mitigation typically focuses on enforcing object-level authorization at every resource-changing endpoint.
Common defensive patterns include:
- Check ownership or an explicitly granted permission before every update and deletion
- Centralize authorization decisions in reusable policy or service-layer functions
- Treat resource identifiers as untrusted input and resolve them within the current user's authorization scope
- Apply deny-by-default behavior for private and user-owned objects
- Use separate administrative authorization paths with explicit privilege checks
- Add regression tests covering cross-user access to all CRUD operations
- Avoid relying solely on client-side filtering, obscured identifiers, or authentication status
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis and code review checks for controller actions that load objects by user-supplied IDs without authorization calls
- Review of PUT and DELETE handlers for missing ownership, role, or policy checks
- Integration tests that attempt cross-account access to each resource type
- API gateway or application policy rules that require object-level authorization before state-changing requests
- Audit logging and alerting for users modifying or deleting resources outside their normal ownership scope
Automated security review tools may help identify direct object references and missing authorization patterns, but endpoint-level tests remain important.
Organizations commonly detect this class of issue through:
- Static analysis and code review checks for controller actions that load objects by user-supplied IDs without authorization calls
- Review of PUT and DELETE handlers for missing ownership, role, or policy checks
- Integration tests that attempt cross-account access to each resource type
- API gateway or application policy rules that require object-level authorization before state-changing requests
- Audit logging and alerting for users modifying or deleting resources outside their normal ownership scope
Automated security review tools may help identify direct object references and missing authorization patterns, but endpoint-level tests remain important.
