convex-authz
Skill68 starsChanged 15 days agoApache-2.0View on GitHub
Audit and harden a Convex app's authorization: identity-from-arg impersonation, missing per-document ownership checks, public queries leaking data by a client-supplied id, and writes into a parent/container the caller doesn't own. Scans for the 4 shapes, applies requireIdentity/requireOwner, verifies with tsc. TRIGGER on 'secure my app', 'audit auth/authz', 'who can access this data'. SKIP when there is no convex/ directory.
6 other projects use a version of this, 2 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- convex/agent-skillsword for word, first seen Oct 17, 2026
- moltbot/molthubword for word, first seen Oct 8, 2026
- clawdbot/clawdhubword for word, first seen Oct 8, 2026
- openclaw/clawhubword for word, first seen Oct 8, 2026
- FabienGreard/TouchGrassBaredited, first seen Sep 8, 2026
- getsentry/fridayedited, first seen Aug 28, 2026
Used with
Projects with it also use convex-acquire-domain, convex-check-updates and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
FabienGreardSkillconvex-acquire-domain
Find and buy a domain for the current Convex app through Convex, then bind it (labs; spend action).
Also in 4 projects that use this
FabienGreardSkillconvex-check-updates
Check the current app's pinned Convex components against recommended versions and upgrade them behind a build gate.
Also in 4 projects that use this
openclawSkillclawhub-ban-appeals
Review ClawHub account-ban appeals, distinguish bans from moderation holds or blocked releases, and prepare an evidence-backed moderation decision. Route validated scanner inaccuracies to clawhub-clawscan.
Also in 3 projects that use this
openclawSkillclawhub-clawscan
Investigate ClawScan health alerts, diagnose scanner or ClawHub integration failures, prepare operational repairs, and route validated verdict inaccuracies upstream. Account ban appeals use clawhub-ban-appeals.
Also in 3 projects that use this
- +8 more from openclaw
Other versions6 projects use a version of this.
Word for word · 4
- openclaw/clawhub★ 9.6k100% same
- clawdbot/clawdhub★ 9.5k100% same
- moltbot/molthub★ 9.5k100% same
- convex/agent-skills★ 68100% same
Edited · 2
- FabienGreard/TouchGrassBar★ 597% same
- getsentry/friday★ 097% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository33 other files it gives its agents.
- AGENTS.mdAGENTS.md
- convex-addSkill
- convex-advisorSkill
- convex-agentSkill
- convex-authSkill
- convex-backupSkill
- convex-billingSkill
- convex-costSkill
- convex-create-componentSkill
- convex-cronsSkill
- convex-deploy-guardSkill
- convex-designSkill
- convex-docsSkill
- convex-domainsSkill
- convex-envSkill
- convex-expertSkill
- convex-explain-appSkill
- convex-improve-convex-pluginSkill
- convex-insightsSkill
- convex-launch-readinessSkill
- convex-migrate-rehearseSkill
- convex-migrateSkill
- convex-monitorSkill
- convex-optimizeSkill
- convex-quickstartSkill
- convex-reviewerSkill
- convex-seedSkill
- convex-self-healSkill
- convex-sentinelSkill
- convexSkill
- convex-suggestSkill
- convex-testSkill
- convex-verifySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Every read or mutate keyed by an _id argument must verify ownership server-side (requireOwner or an inlined equivalent comparison) before …
- Very specific: line 32
Never leave a public query that returns PII/financial/audit data reachable by an unauthenticated or cross-account client-supplied id.
- Distinctive: line 34
Always verify with tsc after hardening.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- GENERATED from convex-agents content/capabilities/convex-authz.json — do not edit by hand. -->Convex Authz Auditor/Hardener
A focused authz specialist, not a general reviewer: it finds and fixes the four shapes that account for the largest real-defect cluster measured against generated Convex backends (25 identity-from-arg + 13 missing-ownership-check + 6 PII-leak-by-argument = 44 of 214 confirmed defects, plus the parent-reference-on-write variant of the ownership shape that fixture measurement showed the 3-shape scan misses). It runs a deterministic scan first (objective, regex-based), then applies the canonical requireIdentity/requireOwner hardening pattern from convex-expert.md to every hit, then verifies with tsc. It does not re-derive the pattern — it applies the one already documented as the platform's canonical fix.
Workflow
- MANDATORY FIRST STEP — check the auth foundation exists before injecting any ctx.auth enforcement: (1) is there an auth.config.ts with a provider? (2) is there a users/identities table keyed to the auth subject (tokenIdentifier/identity.subject)? If EITHER is missing, DO NOT add requireIdentity/requireOwner — on a foundationless app ctx.auth.getUserIdentity() always returns null (enforcement is non-functional: every call 401s, or worse, the check is bypassed/miscompared against a non-subject field like an email string) and a reviewer correctly flags that as a NEW authz defect, not a fix. Instead, on a foundationless app: (a) for privileged/admin operations, convert the public query/mutation to internalQuery/internalMutation (removes public reachability entirely — safe and foundation-free, no ctx.auth needed), and (b) tell the user: 'this app has no auth foundation; run
/add author the auth setup first, then re-run convex-authz to add per-user ownership checks.' Do not run steps 1-3 below against public functions on a foundationless app beyond this internalize-and-defer move. Only when the foundation exists (both auth.config.ts and a subject-keyed users table are present) do you proceed to inject requireIdentity/requireOwner in steps 1-3. - SCAN (deterministic, objective-first): for every convex/**/*.ts file (skip convex/_generated/ and .d.ts), grep for the four shapes:
(a) identity-from-arg: a public
query(/mutation(object whoseargsblock declaresuserId/actorId/ownerId/authorId/accountIdtypedv.id(...), where the function's whole block (args + handler) has zeroctx.authreference. Regex:/\b(userId|actorId|ownerId|authorId|accountId)\s*:\s*v\.id\(/inside anargs: { ... }block paired with an absent/\bctx\.auth\b/anywhere in the enclosing(query|mutation)\(\s*\{ ... }block (word-boundary excludes internalQuery/internalMutation by construction). (b) missing-ownership-check: a publicquery(/mutation(whose handler loads a document viactx.db.get(args.<xId>)(an_id-typed arg) and then callsctx.db.patch/ctx.db.delete/ctx.db.replaceon that same id, or returns the doc's fields directly, with no comparison of any<doc>.<ownerField>against an identity value anywhere in the block (no===/!==involvingidentity.subjector actx.authderived value). (c) PII-leaking public query: a publicquery(whosereturns(or the raw doc it returns) includes a sensitive-looking field (email,revenue,ssn,password,token,auditLog,dashboard-shaped aggregate) and the query is parameterized by a client-supplied id with noctx.authcheck gating access to that id's own scope. (d) parent-reference ownership on write: a publicmutation(whose args include av.id(...)of a parent/container table (projectId,boardId,teamId,orgId,listId,folderId,conversationId,accountId, ...) that the handler uses as a foreign key in actx.db.insert/ctx.db.patch— attaching or moving a child row into that container — without verifying the caller owns (or is a member of) the referenced parent doc. Creating a row inside someone else's container is the same defect as mutating their row: fixing WHO the caller is (shape a) does not fix WHERE they may write. After handling shapes a-c, re-audit every REMAININGv.id(...)arg in every public mutation for this shape — shape-a fixes routinely leave the parent id arg behind, still unchecked. Report every hit with file, line, and which of the 4 shapes matched — this is the objective, model-independent baseline; do not skip it in favor of jumping straight to judgment. - HARDEN (foundation-having apps only — see step 0): for each hit, apply the canonical pattern from content/convex-expert.md verbatim — do not invent a new helper. Add (if absent)
convex/model/auth.tsexportingrequireIdentity(ctx)(throws 401 ifctx.auth.getUserIdentity()is null; returns the identity) andrequireOwner(ctx, doc)(throws 404 if doc is null, throws 403 ifdoc.ownerId !== identity.subject, else returns doc). Rewrite each flagged function: replace the client-supplied identity arg withrequireIdentity(ctx); wrap each_id-keyed read/mutate withrequireOwner(ctx, await ctx.db.get(args.xId))before touching the row; scope each PII-returning query throughrequireIdentity/requireOwner(or an explicit staff/role check) before it reads outside the caller's own scope; for each shape-(d) hit, load the referenced parent doc and applyrequireOwner(ctx, parent)(or the schema's membership check — e.g.participantIds.includes(user._id)— when the container models members as an array) BEFORE inserting/patching the child row. When the schema keys ownership by ausersrow id rather than the raw subject, resolve the caller'susersrow first (via the subject-keyed index) and compare againstuser._id— comparing anId<"users">field toidentity.subjectnever matches and silently breaks enforcement. Never widen scope — an internal/admin function that legitimately operates on an arbitrary user staysinternalQuery/internalMutation, never public; leave it unflagged and unchanged. - VERIFY: run
npx tsc --noEmit(or the project's typecheck script) after edits; a hardening pass that doesn't typecheck is not done. Then re-run the step-1 scan to confirm 0 remaining hits (the fixed shapes no longer match the regexes becausectx.authnow appears in-block and ownership comparisons now exist). - Report findings grouped by the 4 rule shapes with file:line, explain why each is exploitable (who could impersonate whom / read whose data), and show the concrete diff applied (or, on a foundationless app, the internalize-and-defer diff plus the auth-setup nudge) — never just describe the fix in prose.
Rules
- MANDATORY FIRST STEP: before injecting requireIdentity/requireOwner, verify the auth foundation exists — an auth.config.ts with a provider AND a users/identities table keyed to the auth subject. If either is missing, do not add ctx.auth-based enforcement (it's non-functional or mismatched and creates a NEW authz defect); instead convert flagged public admin/privileged functions to internalQuery/internalMutation and tell the user to run auth setup first, then re-run convex-authz.
- Scan objectively before judging — run the 4 deterministic greps first; don't skip straight to LLM judgment, and don't let a clean scan stop you from still eyeballing internal/admin exemptions.
- Identity always comes from ctx.auth, never from a client-supplied argument — the one legitimate exception is an internalQuery/internalMutation/internalAction that is never exposed publicly.
- Every read or mutate keyed by an _id argument must verify ownership server-side (requireOwner or an inlined equivalent comparison) before touching the row — being logged in is not the same as owning this row.
- Any v.id(...) argument a public mutation uses as a foreign key when inserting or moving a row must have the referenced parent's ownership (or membership) verified against the caller first — creating a child row inside someone else's project/board/account is the same defect as mutating their row, and it survives an identity-from-arg fix unless checked separately.
- Never leave a public query that returns PII/financial/audit data reachable by an unauthenticated or cross-account client-supplied id.
- Reuse requireIdentity/requireOwner from content/convex-expert.md verbatim — do not fork a parallel helper or invent new error semantics.
- Always verify with tsc after hardening; a fix that doesn't typecheck is not shipped.
- This is a targeted authz pass, not a general code review — do not expand scope into performance/schema/validator findings; hand those to convex-reviewer.
- SKIP entirely when there is no convex/ directory in the project.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

