Security overview

Areca holds unpublished client content, publishes it to live websites, and stores keys for deployment and AI services. This section explains how it protects those things, what you must configure yourself, and where the limits are.

The most important rule is that access is enforced on the server. The interface hides actions you cannot take, but hiding is not what stops you. Every request is checked against who you are, which role you have and which client the data belongs to.

The security modelCopy Anchor Link

• Server-enforced authorization. Each request is checked against the signed-in user, their role and their client before any data is read or changed. A denied request returns no data and changes nothing. See roles and permissions.
• Two-factor authentication for agency admins. Agency admins must set up an authenticator app before they can use admin functions. This is on by default. See two-factor authentication and step-up.
• Step-up checks. The most sensitive actions, such as deleting a client or a site, rotating a site token, or changing a stored API key, need a recent sign-in or a recent authenticator code. A session is recent for 10 minutes after it starts or after a code is confirmed. When it is not, Areca asks for a code.
• Scoped tokens. Each site project has a read-only site token and a separate schema-write token. Preview links are signed and expire after one hour. An AI app connected through OAuth acts as you on one site, and so does a personal AI key. You can disconnect the app or revoke the key at any time. See tokens.
• Encrypted stored keys. Deployment and AI API keys are encrypted at rest with a key you supply. Site tokens are stored only as hashes. See secrets and encryption.
• Rate limits. Writes, uploads, site API calls, AI suggestions, and metrics requests are limited, and repeated wrong two-factor codes lock step-up. See rate limits.
• Errors that reveal little. Unexpected server errors return a generic message with a reference ID, and the details stay in the server log. A request for an object in another client gets the same answer as a request for an object that does not exist.
• Tested rules. The authorization rules are written as a matrix and checked automatically against a real database, covering every server action and API route. See the permissions matrix.

What you need to knowCopy Anchor Link

• Social and single sign-on skip the sign-in authenticator prompt. Signing in with GitHub, Google, Discord, or Microsoft does not ask for a code at sign-in. When ADMIN_MFA_REQUIRED is on, agency admins still need two-factor enabled and must verify a local TOTP or backup code in that session before using admin functions.
• Your instance, your keys. You generate and keep the secrets that protect sessions and stored keys. Losing an encryption key means re-entering the keys it protected. See secrets and encryption.
• Backups are your responsibility. Areca does not schedule backups. A backup contains the encrypted keys and the database, so protect it as you would the live system. See backup and recovery.
• Rate limits use Redis when available. If Redis is unavailable, request limits continue with the same budgets in memory on each CMS instance, but counters are no longer shared across instances. Sign-in and two-factor limits are also kept in memory per instance. See rate limits for details.

Find your topicCopy Anchor Link

RelatedCopy Anchor Link

• Self-hosting configuration lists every environment variable mentioned in this section.
• Authentication covers sign-in methods and their setup.
• Library explains how files are uploaded and shared.