Hasura permissions security review cost: $2,400 once

Hasura permissions security review cost is $2,400 once for one app whose GraphQL API is Hasura on Postgres. $1,200 starts the work. The report is due 48 hours after a test user can sign in. You own the PDF. There is no subscription.

Hasura’s roles live in the engine. They are not Postgres roles. A filled cell in the permissions grid is not a review.

Short answer: Hasura permissions security review cost is $2,400 once, with $1,200 to start, for one app. I check the live screens, the login, and the Hasura role permissions those screens already trust, then write the report 48 hours after access works. You own it. Hasura’s hosting bill and a multi-week accredited pentest are different products. The offer is the web application security review.

What does a Hasura permissions security review cost?#

$2,400 once for one app, $1,200 to start, the rest when the PDF lands. You own that file. You are not buying Hasura Cloud, a scanner login, or a stamp I do not hold.

Hasura’s authorization docs say role permissions live in the engine and have no relationship to database users and roles. This price tests the gate the browser already hits.

What you are buying	2026 price	What you actually get
This Hasura permissions review	$2,400 once, $1,200 to start	One app, the role rules the engine is running, the UI that trusts them, report in 48 hours, one retest
Hasura engine, Cloud or self-hosted	Your hosting bill	The GraphQL API. Not a test of which role can read which row
Automated scan	About $100–$3,000	Mostly a known-bug list (WardenBit)
Small web app pentest	$2,500–$15,000, or $4,000–$12,000	A longer calendar, often aimed at a compliance packet (SecureLeap)

The same review at month 12 and month 24 is $7,200 over three years, one payment each time. That does not buy a CREST letter. The price is also on pricing.

A row policy inside Postgres is a different product. That writeup is Supabase RLS security review. This one is the Hasura metadata the GraphQL request actually uses.

What do those role permissions decide for a signed-in user?#

I sign in as the users you already ship and record which rows and columns those sessions can open. The pass covers the pages, the login, and the rules the engine is running. The admin secret is a different key, and it does not belong in the browser.

The bar is Hasura’s own permission model:

• A request carries X-Hasura-Role and the session variables your auth service set. Rules are per role, per table, per operation (configuring permissions).
• Select can limit rows, columns, aggregations, and how many rows come back. Column permissions decide which fields of an allowed row are visible (column permissions).
• “Without any checks” is an empty filter. Hasura’s role examples say that condition allows every row. A public role with that filter and a sensitive column is a hole, not a placeholder.
• Insert uses a check and can preset columns. Update has a pre-update filter and a post-update check (row permissions). A user who can write a row they should not own is a finding. I do not paste a way to do it.
• The admin secret, sent alone, bypasses permissions. The admin role does the same. Hasura’s admin access page says that secret should never sit in a front-end client. I record whether the browser sends it. I do not take the secret.
• In JWT mode the token must carry x-hasura-default-role and x-hasura-allowed-roles. A client may name x-hasura-role only if that role is already allowed (JWT auth). I check the roles the test users can assume.

The document shape is the sample pentest report. No client names.

What is not included for $2,400?#

You get severity, table, role, operation, and a fix an engineer can ticket, for one authorized app. I do not ship exploit steps, a metadata rewrite, a second app, or a certificate I do not hold. The PDF is yours. There is no monthly fee.

A second app, a mobile binary, a network red team, and applying the permission change are separate quotes. If the admin secret is already in the client, I write that down. Moving it is your engineer’s job. If a screen calls an action or a remote schema, I record the role. Rewriting that handler is not in this price.

This is not AI Front Door, where a customer books or pays from ChatGPT, Claude, Grok, or another AI app that supports MCP connectors. MCP is the open standard those apps use to connect to a business’s tools. It is not Workflow Automation either. That offer is $3,500 once for one repeating ops job, such as an invoice chase, and it does not read Hasura metadata.

How does the review run from access to the PDF?#

You authorize one URL, I use the test logins you send, and the clock starts when that login works. The running permissions decide the row and the column. The PDF is what you keep. I do not apply a metadata change inside this price.

Step	What happens
Trigger	Customer rows are live through Hasura, or a buyer asked which role can still read them
Action	I walk the live UI as each test user and compare that session to the role rules the engine is running
System of record	That metadata, plus the written findings: severity, table, role, operation, fix
Human escalation	You ticket the change. I do not edit production permissions inside this price

Send written authorization, one working test user, and a second user when two customers must not see each other. Say which tables a signed-out visitor may read. Name the engineer who owns the metadata. One free retest of that same URL is included within 14 days.

When this isn’t the right move yet#

Do not pay the $1,200 if I cannot legally open the app, or if a buyer named a certificate this offer does not include. Get a URL and two test users first. A pass with no login is a homepage skim.

Wait if nobody can sign in as two customers today. Hire the firm that holds CREST if the questionnaire requires that name. If the endpoint is not Hasura, say so before you pay. The same web application security review still covers auth and the API. A missed phone is the receptionist, $8,000 once, not this review.

What should be true before I start?#

Bring the URL, two users, and one sentence on what is public. I start from the permissions the engine is running. I cannot start without a login that behaves like production.

Before you pay, confirm these:

• The URL I may use, in writing.
• One user who should see their own rows, and a second user who must not.
• Which role a signed-out visitor uses, and which tables that role may read.
• That the admin secret stays on a server, not in the app binary or the browser.
• That someone can show the permissions metadata if the git file and the running engine disagree.

If you want the layout before credentials, ask for the sample from the contact form.

$1,200 reserves the work on the review page. I confirm scope in writing before I start. The form is short. I reply with the replacement map within 24 hours. If you would rather talk through the workflow for 20 minutes and see whether this fits, book a 20-minute call.