Security

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.

You install and use the software and any module entirely at your own risk. The software is provided "as is" and "as available" without warranty of any kind. We make no guarantees regarding reliability, security, availability, or fitness for any purpose. You are solely responsible for securing the software and any environment in which it runs. This includes server security, access controls, encryption, patching, monitoring, backups, and compliance with applicable laws. We disclaim all liability for damages arising from use of the software, including data loss, security breaches, unauthorized access, system failures, or business interruption. You are strongly advised to implement and regularly test backup procedures. We are not responsible for any data loss.

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.

Data Isolation

ARI uses a layered model to keep each user's data scoped to that user:

• Application-level filtering (primary). Every API route calls getAuthenticatedUser() and uses the returned withRLS() helper, which opens a transaction, sets a per-request user context, and runs queries that explicitly filter by user_id. This is the line of defense that actively prevents cross-user reads and writes.
• PostgreSQL RLS policies (defense-in-depth). Every table ships with row-level security policies keyed on the per-request user context. These activate as a fallback if you connect using a restricted database role; the default postgres role used by most local and Supabase deployments bypasses RLS, so it serves as defense-in-depth rather than the primary control.

Module developers must use withRLS() for all database access. The /ari-create-module command enforces this by default, and /ari-audit-module flags routes that miss it.

For the full layered model and the optional restricted-role hardening, see the engineering security doc.

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
• Referrer-Policy — Strips referrer info on cross-origin requests
• Permissions-Policy — Disables camera, microphone, and geolocation by default
• X-Robots-Tag — Prevents the app from being indexed by search engines

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
• Two-factor (TOTP) verification: 5 attempts per minute
• All other auth endpoints: 30 requests per minute (default)

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.

Security Best Practices

• Use strong, unique passwords and a password manager
• Enable two-factor authentication for your admin account
• Use HTTPS in production (automatic on Vercel)
• Set ALLOWED_IPS if your access patterns are predictable
• Run /ari-audit-module on custom modules before deploying
• Keep ARI updated with /ari-update to receive security patches
• Rotate API keys periodically
• Keep your operating system and server software up to date
• Use a firewall to restrict access to only necessary ports
• Regularly back up your database and test your restore process
• Regularly monitor server logs