- Home
- Skills
- Waynesutton
- Convexskills
- Convex Security Audit
convex-security-audit_skill
- JavaScript
225
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill waynesutton/convexskills --skill convex-security-audit- SKILL.md14.5 KB
Overview
This skill provides a focused security-audit checklist and reusable patterns for Convex apps, covering authorization, data boundaries, action isolation, rate limiting, and protection of sensitive operations. It packages concrete code patterns and operational recommendations to harden production Convex backends and prevent common mistakes.
How this skill works
The skill inspects key server-side areas: role and permission enforcement, database query filtering to enforce ownership, isolation of external API calls and secrets, request rate tracking, and multi-step safeguards for destructive actions. It supplies code examples and validators you can adapt, plus logging and scheduler patterns to avoid inline destructive work.
When to use it
- Before deploying Convex functions to production
- When implementing new queries/mutations that return user data
- When integrating external APIs or payment providers
- When adding admin or destructive operations (deletes, migration jobs)
- When you need to prevent abuse through rate limits
Best practices
- Enforce least privilege with requireRole/requirePermission helpers
- Always filter DB queries by user identity or access lists to avoid data leaks
- Keep external API keys in environment variables and never return them
- Isolate sensitive logic in internal actions or internalMutations and schedule heavy tasks
- Record audit logs for sensitive operations and require confirmation codes for destructive actions
- Apply rate limiting per action and record requests to compute retry windows
Example use cases
- Protecting user-owned records so queries return only items where ownerId == current user
- Wrapping Stripe or other payment calls in internal actions and never exposing keys or raw errors
- Implementing a per-user messaging rate limiter to prevent spam
- Creating a two-factor confirmation flow for global data deletion and scheduling the actual deletion
- Maintaining an internal auditLogs table with internalMutation logging for compliance reviews
FAQ
Return null or a generic response when ownership checks fail so callers can’t infer existence.
Where should API keys and secrets live?
Store secrets in environment variables and access them only inside server-side or internal actions; never include them in responses or client-exposed code.