RowShield vs 42Crunch: contract auditing versus permission reality

Head to head: 42Crunch vs RowShield

Column claims about 42Crunch are sourced below. Where the edge is theirs, the page says so — and the sections that follow explain why Supabase teams still pick RowShield.

What 42Crunch does

42Crunch built a platform around the OpenAPI contract. Static auditing scores specifications against hundreds of quality and security checks, conformance testing compares live traffic with the declared contract, and a runtime firewall derives protection configuration from the specification itself. Everything integrates into development pipelines, so defective contracts stall at pull request rather than reaching production.

For organisations whose API surface is genuinely documented, the discipline pays off. The premise deserves scrutiny, though: it presumes a faithful, maintained description of the API exists at all.

Where the scopes differ

PostgREST can emit an OpenAPI description of your tables and remote procedure calls, and 42Crunch could audit that document. What the description cannot express is the row level security logic deciding who may read what; two deployments with byte-identical specifications can differ completely in permission outcomes.

RowShield reads the thing itself: policies as stored, grants as issued, functions as defined. One product perfects the map, the other patrols the territory, and authorisation failures live exclusively in the territory.

A concrete illustration: add a column, forget a policy, and the generated OpenAPI document updates itself to describe a table that every anonymous visitor can now read in full. The specification remains flawless throughout; only a monitor that evaluates permissions would raise an alarm.

Why Supabase teams choose RowShield over 42Crunch

In a Supabase project the contract is generated and the security is declarative SQL, which inverts 42Crunch’s assumptions. RowShield embraces that shape: continuous evaluation of every policy, unauthenticated probing of the PostgREST surface, drift detection on each migration, storage and function checks included.

Findings are written for humans and paired with corrected statements. Nothing depends on documentation discipline, and nothing waits for a pull request to catch what a migration already broke in production tonight.

There is also the question of who reads the output. Contract-audit findings speak fluent specification dialect and land best with platform architects; RowShield findings name your tables and columns in ordinary sentences, which means the developer who introduced the regression can fix it without translation.

Where 42Crunch is the right choice

Enterprises publishing formal API programmes, running design-first workflows and holding contractual commitments to partners get real value from contract auditing and spec-derived firewalls. That is conceded without reservation.

The pivot for Supabase teams: your API documentation is a by-product, your security lives in policies, and the failure mode that matters is a permissive clause already in production, not a malformed schema next sprint. Different problems deserve different instruments.

Using both

There is no conflict. Teams maintaining OpenAPI artefacts for external consumers keep 42Crunch guarding their quality while RowShield guards the database underneath. The artefacts cooperate in review, too: a contract finding explains what callers expect, a policy finding explains what the database permits, and reconciling the two is precisely what a security reviewer wants on the table.

Frequently asked

Is RowShield affiliated with 42Crunch?

No. RowShield is a Veristria product and has no relationship with 42Crunch. Their name and marks are theirs, and our account of their platform draws solely on public sources reviewed on 2026-08-23.

Could we use 42Crunch and RowShield side by side?

Yes, without overlap. Contract auditing addresses documentation quality and pipeline discipline; RowShield addresses live authorisation in Postgres. Organisations with formal API programmes often end up wanting exactly one of each.

PostgREST already emits an OpenAPI document; is auditing it sufficient?

That document enumerates endpoints and shapes, not permission outcomes. Two databases with identical documents can allow entirely different access, so only direct evaluation of the policies themselves establishes the truth, which is RowShield’s entire method.