Module Security

Built-In Security Audit

Every module you build deserves a thorough review. ARI ships with a powerful audit tool that checks your module across dozens of security, performance, and quality dimensions — all from a single command.

/ari-audit-module

The audit is completely read-only. It never modifies your code or executes SQL. It reads your module's files, analyzes them against ARI's security standards and best practices, and produces a clear, actionable report.

What It Checks

The audit runs four parallel checks that cover every layer of your module:

Security (16 categories)

The core of the audit. Every API route, component, database schema, and configuration file is examined for vulnerabilities:

• Authentication & Authorization — Missing auth checks, user ID taken from request body instead of session, routes accessible without proper permissions
• Input Validation — Missing Zod validation, unvalidated query parameters, mass assignment risks
• SQL Injection — Raw SQL with string interpolation, dynamic table names from user input, unparameterized queries
• Data Exposure — Hardcoded API keys, stack traces returned to clients, secrets in code or config files
• Cross-Site Scripting — Unsanitized user input, dangerouslySetInnerHTML without protection, unvalidated URLs
• File Upload Security — Missing type validation, size limits, path traversal risks
• Multi-Tenancy — Queries missing user isolation, cross-tenant data leakage
• And more: CSRF protection, rate limiting, dependency vulnerabilities, cryptography, SSRF, Next.js-specific issues

The audit also runs a hardcoded credential scan across every file in your module — TypeScript, JSON, SQL, Markdown, everything — looking for accidentally committed API keys, tokens, and secrets.

Production-Readiness

Ensures your module follows ARI's architecture patterns and will work correctly when installed:

• Manifest validation — module.json exists, has required fields, ID matches folder name
• Self-containment — All module code lives inside the module directory, no files scattered across the project
• Database schemas — SQL is idempotent, RLS is enabled, user_id uses the correct type, no destructive operations in install scripts
• API patterns — Routes use withRLS(), responses use toSnakeCase(), proper HTTP status codes, consistent error shapes
• Registration — Module is properly registered in all required system files

Database Best Practices

Analyzes your SQL schemas and queries for performance and correctness:

• Missing indexes on frequently filtered columns
• Unsafe RLS policy patterns
• Suboptimal column types
• Inefficient query patterns

Frontend Quality

Checks your components and hooks against ARI's gold-standard patterns:

• Performance — Unbounded queries without pagination, N+1 patterns, heavy imports that should be lazy-loaded
• Data Fetching — Modules should use TanStack Query hooks, not raw fetch() calls. The audit checks for missing hooks, inline query keys, stale cache after mutations, and pre-migration auth patterns
• UX Quality — Loading states, empty states, error states, double-submit prevention on mutation buttons, confirmation dialogs on destructive actions
• Accessibility — Missing labels on interactive elements, form inputs without associated labels, color-only status indicators

The Report

The audit produces a single consolidated report with every finding categorized by severity:

• High — Immediate risk. Auth bypass, data exposure, destructive SQL, missing RLS.
• Medium — Significant weakness. Missing validation, unsafe error responses, unbounded queries.
• Low — Best-practice gaps. Missing optional fields, convention violations, minor UX improvements.

Each finding includes the exact file and line number, a clear description of the issue, and a specific recommendation for how to fix it. The report ends with a Top 5 priorities list so you know exactly where to start.

Usage

Run the audit from your Claude Code workspace:

/ari-audit-module tasks

If you run /ari-audit-module without specifying a module, it will list all available modules and ask you to pick one.

The audit covers one module per run to keep the report focused and readable. Run it after creating a new module, after making significant changes, or as a routine check before sharing your module with others.