Overview
ARI is designed with a defense-in-depth security model. Multiple layers of protection ensure your personal data stays private, even if one layer is compromised.
Authentication
ARI uses Better Auth for session management with email and password authentication. Sessions are valid for 30 days with HTTP-only cookies and a 5-minute cache TTL. Public sign-up is disabled — only the admin account created during setup can access the instance.
See Authentication for full details including 2FA and rate limiting.
Row-Level Security (RLS)
Every database table in ARI is protected by PostgreSQL row-level security. The withRLS() helper function ensures all queries are scoped to the authenticated user. Even if a query is malformed or a module has a bug, RLS prevents data from leaking across user boundaries.
Module developers must use withRLS() for all database access. The /ari-create-module command enforces this by default.
Password Hashing
ARI uses Argon2id for password hashing — the current recommended algorithm for password storage. Argon2id is resistant to both GPU-based and side-channel attacks.
Security Headers
ARI sets security headers on all responses:
- Content-Security-Policy (CSP) — Restricts which resources the browser can load, preventing XSS and data injection attacks
- Strict-Transport-Security (HSTS) — Forces HTTPS connections, preventing protocol downgrade attacks
- X-Content-Type-Options — Prevents MIME type sniffing
- X-Frame-Options — Prevents clickjacking by blocking iframe embedding
Rate Limiting
Authentication endpoints are rate-limited to prevent brute-force attacks:
- Sign-in: 5 attempts per 5 minutes
- Sign-up: 3 attempts per 5 minutes
IP Allowlisting
Restrict access to your ARI instance to specific IP addresses or hostnames using the ALLOWED_IPS environment variable. The middleware blocks all requests from non-allowed sources.
See Authentication for configuration details.
Middleware Protection
All routes in ARI pass through authentication middleware. Unauthenticated requests are redirected to the login page. Only explicitly marked public routes (like the login page itself and API endpoints with their own auth) bypass this check.
Input Validation
API routes use Zod schema validation for all input. This prevents injection attacks and malformed data from reaching the database. The /ari-create-module command scaffolds Zod validation by default.
Best Practices
- Enable two-factor authentication for your admin account
- Use HTTPS in production (automatic on Vercel)
- Set
ALLOWED_IPSif your access patterns are predictable - Run
/ari-audit-moduleon custom modules before deploying - Keep ARI updated with
/ari-updateto receive security patches - Rotate API keys periodically