Look twice.Find the gem.

AI agents and MCP servers, each published with its source and what the checks found.

Marketplace

  • Everything
  • AI agents
  • Apps
  • MCP servers
  • Templates
  • What people want
  • What changed this week
  • The verification standard
  • The ooruby Index
  • Servers that publish no source
  • Reliability guides
  • What the catalogue holds
  • Sell here

Our library

  • Everything, in one place
  • Guides
  • Glossary
  • Calculators
  • Checklists and cheat sheets
  • Community

ooruby

  • Home
  • For teams
  • Site status
  • Company projects
  • RSS feed

Verification records what our published tests found on a specific version at a specific date. It is not a warranty, and it does not certify that software is free of defects.

Rubricv1.0
AI agentsAppsMCP serversTemplatesWantedCommunityOur library
Sign inSell
Back to the standard
rubric v1.0

Row-level security

The database refuses rows the current user is not entitled to, verified with two accounts.

Applies to
apps
Standard references
CWE-285

A finding here is not a failure

Software of any size carries something. A listing that raises findings on this check is still sold, with the findings published and their severity and reachability stated. A badge that only ever said pass would teach people to stop reading it.

Explainer · 2026-09-30

Row-level security: making the database refuse rows a user is not entitled to

If an application's database is reachable with a public key, row-level security is the only thing standing between one user and another user's rows. It has to be on, and it has to be right.

What this row checks

That the database itself refuses rows the current user is not entitled to, verified with two accounts: one account creates data, the other tries to read and change it, and every attempt that should fail does.

How it works in Postgres

Row security is switched on per table, and policies say which rows each role may see or change. With it switched on and no policy at all, Postgres denies everything by default. Superusers and roles with the bypass attribute always skip it, and table owners normally do too unless the table is set to force it.

Platforms built on Postgres, Supabase among them, hand browsers a public key and rely on row-level security to decide what that key can reach. A table with it switched off is readable by anybody holding the public key.

The usual mistakes

Leaving a new table without row security because the first one had it. A policy that trusts a value the user can edit. A view that runs with its owner's rights and quietly reads past the policies on the tables beneath it. Each passes a test with one account and fails the moment a second account tries.

Sources

  1. PostgreSQL documentation: Row Security Policies
  2. Supabase Docs: Row Level Security
  3. CWE-285: Improper Authorization

How apps and templates are read for this row

On an app or a template, this row is also answered every night by a reading of the package's published files, never by running it. The rules are app check set v1.0, each with its mapping, an example, the nearest writing it leaves alone, a hand count across every app and template listing, and what a reading of files does not cover.

In the glossary: RLS.

What this check has found

Nothing in the catalogue has raised a finding on this check. That is a fact about what has been tested so far rather than a guarantee about what is out there, and it is printed because a check that never fires is worth knowing about too.

Other checks

No shipped credentialsDependency advisoriesBehaviour matches the manifestDeclared egressData handling disclosedLicence and provenance

Every listing in the catalogue shows its result on this check, with the findings summarised in public and the full report to whoever bought it. Open the catalogue.