Hasura Security Scanner — anon-role GraphQL leaks avatar

Hasura Security Scanner — anon-role GraphQL leaks

Pricing

Pay per usage

Go to Apify Store
Hasura Security Scanner — anon-role GraphQL leaks

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

Renzo Madueno

Maintained by Community

Actor 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 anon role's row checks ship with with no check selected 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:

  • $29 quick scan + 1-page report in 24h (Stripe) — for when you want a sanity check before committing
  • $99 full turnkey audit + anon-role rewrites + verification, 48h, money-back (Stripe)

⭐️ 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:

  1. Copy-pasted permissions from a tutorial that says "let anon read posts" → bleeds into adjacent tables (users, sessions)
  2. Row aggregation enabled on the anon role → _aggregate { count } leaks row totals even when individual reads are blocked
  3. Hasura Cloud free-tier templates ship with anon SELECT enabled on demo tables so you can test
  4. 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:

  1. Leave inputs empty + click Run for a DEMO sample report
  2. Provide your graphqlUrl to 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 role
Total records: 18,943
Sample columns: id, user_id, token, expires_at, user_agent, ip_address, created_at
Sensitive columns detected: token, ip_address
Reproducer:
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)

  1. Open Hasura Console → Data
  2. Click the leaky table
  3. Click Permissions tab
  4. Click the row for the anon role
  5. 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
  6. 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: 1 to confirm exposure without exfiltrating contents

Built by Renzo.