Hasura Security Scanner — anon-role GraphQL leaks
Pricing
Pay per usage
Hasura Security Scanner — anon-role GraphQL leaks
Probes a public Hasura GraphQL endpoint for tables readable by the anon role. Works for self-hosted, Hasura Cloud, and frameworks on top. Counts only.
Pricing
Pay per usage
Rating
0.0
(0)
Developer
Renzo Madueno
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
19 hours ago
Last modified
Categories
Share
Hasura Security Scanner — Find anon-role table leaks
Hasura's permission UI is per-role per-table — and the
anonrole's row checks ship withwith no checkselected in every copy-pasted tutorial. That single dropdown leaks every table the anon role has SELECT on. This actor finds those leaks in 30 seconds.
Probes a public Hasura GraphQL endpoint (self-hosted Hasura, Hasura Cloud, or any framework on top) for tables readable by the anon role. Sends _aggregate { count } + sample queries per table. Counts only — never row data.
💸 Two ways to get this fixed:
⭐️ Solo dev competing with bigger Apify publishers. A 30-second review is the single thing that lifts ranking. Thank you.
Why this exists
Hasura is the GraphQL standard for many teams — but its permission model is easy to get wrong. The anon role is the role used when no auth token is sent, and Hasura applies it across every table query unless you explicitly deny it. Common ways anon SELECT leaks happen:
- Copy-pasted permissions from a tutorial that says "let anon read posts" → bleeds into adjacent tables (users, sessions)
- Row aggregation enabled on the anon role →
_aggregate { count }leaks row totals even when individual reads are blocked - Hasura Cloud free-tier templates ship with anon SELECT enabled on demo tables so you can test
- Permission migrations sometimes don't apply cleanly and the anon role inherits prior permissive state
This scanner probes ~32 common table names (users, orders, sessions, posts, etc.) plus any hints you pass. It runs two queries per table: _aggregate { count } (proves exposure) + (limit: 1) { __typename } (sample row).
How to run
Either:
- Leave inputs empty + click Run for a DEMO sample report
- Provide your
graphqlUrlto scan your actual endpoint
{"graphqlUrl": "https://your-app.hasura.app/v1/graphql","tableHints": ["custom_table", "schema_v2"],"outputFormat": "both"}
What you get
- HTML report in run's KV store: severity-coded findings, copy-pasteable curl reproducers, exact Hasura Console steps to fix
- Dataset rows: one structured row per finding
Sample finding
[CRITICAL] sessions — readable by anon roleTotal records: 18,943Sample columns: id, user_id, token, expires_at, user_agent, ip_address, created_atSensitive columns detected: token, ip_addressReproducer:curl -X POST 'https://your-app.hasura.app/v1/graphql' \\-H 'content-type: application/json' \\-d '{"query":"{ sessions_aggregate { aggregate { count } } sessions(limit: 1) { id user_id } }"}'
How to fix (Hasura Console)
- Open Hasura Console → Data
- Click the leaky table
- Click Permissions tab
- Click the row for the
anonrole - For SELECT: set a row check anon cannot satisfy (e.g.,
user_id _eq X-Hasura-User-Id— anon doesn't carry this), or delete the permission entirely - Click Save then re-run this scanner
Ethical use
- Only scan endpoints you own or have explicit permission to scan
- Probe queries use
_aggregate+limit: 1to confirm exposure without exfiltrating contents
Related
- $29 quick scan + report: buy.stripe.com/00w4gz9TWef0dWV4r0cAo0u
- $99 turnkey full audit: buy.stripe.com/00w9AT9TWdaW7yx9KkcAo01
- Weekly auto-scans ($29/mo): rls-monitor.vercel.app
- Sister scanners: Supabase, Firebase, Strapi, Directus, Payload CMS, Convex, PocketBase, Appwrite, Nhost (Hasura on Nhost).
Built by Renzo.