Please report security issues privately through GitHub's security advisory form rather than opening a public issue. You'll get a response within a few days.

Running agobackup means giving it credentials that can read everything in your ArcGIS organization, and write to it when you ask for a restore. It's worth being clear about what that implies.

ArcGIS credentials. A username and password, encrypted at rest (Fernet, AES-128-CBC with HMAC) with a random key generated on first start and kept in the data folder as secret.key, or with AGOBACKUP_SECRET_KEY if you set one yourself. ArcGIS Online offers no long-lived unattended credential that can perform the portal export operation. API keys cannot hold admin privileges, so a real account is the only option available, not a shortcut taken here.

Object storage credentials, if you configure an S3 target. Encrypted the same way.

Your GIS data. Backups are written unencrypted to whatever storage you point them at. Anyone who can read that directory or bucket can read your data. If that's a concern, use an encrypted filesystem or bucket-level encryption; client-side encryption is on the roadmap but not implemented.

Web UI login. A single admin account, password hashed with scrypt (N=2^15) from the standard library.

• Protect the data folder, and keep it. It holds secret.key, which decrypts every stored credential. Losing it means stored credentials can't be decrypted, and changing the key has the same effect. Anyone who can read that folder can read the ArcGIS password out of the database. Set AGOBACKUP_SECRET_KEY yourself if you would rather the key lived in a secrets manager than on disk beside the database it protects.
• Don't expose it to the internet without a reverse proxy terminating TLS, and set AGOBACKUP_SECURE_COOKIES=true when you do. There is no rate limiting on the login form.
• Give the ArcGIS service account only what it needs. It does need the default administrator role to export items it doesn't own, which is an ArcGIS restriction, but it should be an account created for this purpose, not a person's.
• Restrict the backup directory. It contains your organization's data in readable form.

• No multi-user accounts or roles. The Activity page records what happened to each backup and what caused it, but with a single login it cannot tell you who. Every action is attributed to the one account.
• No brute-force protection on the login form.
• Backups at rest are not encrypted by agobackup itself.
• The web UI has no CSRF tokens; it relies on SameSite=Lax cookies. Don't put it on a shared host with untrusted users.

These are honest gaps in an early project rather than oversights, and each is worth fixing. Contributions welcome.