# STAFF member with NO Explicit permissions can view `ActivityFeed` via GraphQL

A staff member with zero assigned permissions could read the store's activity feed via the GraphQL ActivityFeed query, bypassing the Home permission gate.

- Payout: $500
- Severity: low
- Program: Shopify
- Credited: h13-
- Disclosed: 2019-06-18
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/528940
- Library page: https://bugbountylibrary.com/r/h1%3A528940
- Tags: domain:web kind:bounty platform:hackerone sev:low tech:graphql technique:regression vuln:access-control vuln:auth-bypass

**Target:** Shopify admin GraphQL endpoint /admin/api/graphql (staffMember.privateData.activityFeed)
**Root cause:** The GraphQL ActivityFeed resolver on staffMember.privateData did not enforce the Home permission required to view the activity feed, unlike the admin UI route.
**Steps:**
1. Create a staff member with no explicit permissions assigned by the Owner.
2. Log in as that staff member and confirm /admin/activity is blocked in the UI.
3. Send `POST /admin/api/graphql` with operationName ActivityFeed querying `staffMember { privateData { activityFeed(first: 20) { edges { node { author createdAt messages topic attributed } } } } }`.
4. Observe the response returns the store's activity feed entries despite no permissions.
**How found:** Noticed ActivityFeeds had migrated to a GraphQL call and tested whether the new resolver enforced the same permission as the admin UI route, similar to prior report #95589.
**Exploitation:** Authenticated low-privilege staff account directly queries the GraphQL endpoint with the ActivityFeed operation; the resolver returns activity feed data without checking the Home permission, leaking store activity to an unprivileged insider.
**Insight:** When a feature migrates from a REST/UI route to GraphQL, re-test the new resolver against the old permission model — the UI gate often isn't replicated in the new field resolver, especially on nested privateData objects.