Because Firefly III stores personal financial information it's important to know how Firefly III is secured, and how it's not.
The database is not encrypted, and data in the tables of the database is readable for humans. Make sure that you use a strong password to authenticate to the database and create a dedicated user for the Firefly III database. Whenever possible, use the disk encryption feature of your operating system to encrypt the disk on which the database is stored.
When you connect your Firefly III instance to the internet, make sure that the database can't be connected to from the web, but only from localhost. Preferrably, the database host can only be reached from the Firefly III host.
ID's used for objects in Firefly III are incremental numbers. Logged in users may infer the existence of objects owned by other users by changing the ID in the address bar and observing 404's. This is not possible for guests.
Up until Firefly III v4.7.9 (December 2018) the database was partially encrypted by Firefly III. Descriptions and other values were encrypted using AES and decrypted transparently. This adds security because if the database is taken, the values are unreadable without the key. This is no longer the case.
Sessions and logins
Sessions are not tied to an IP address. Use 2FA when you can, which is a feature of Firefly III. There is a button on the
/profile page that allows you to logout other sessions so you can make sure there's a limited number of logged in sessions out there.
After the first user has registered themselves, future registrations are blocked. It can be enabled again under
/admin. Each user is strictly separated from other users. Users can't see or detect other users, although they can infer their existence through their user ID (see the preceding text).
The very first user who registers on your instance of Firefly III gets assigned the "owner"-role. Users with the "owner" role can block other users, make them owner as well, but also change their password and/or email address.
Login attempts are capped; guests can't brute-force their way in.
When a user logs in from a new IP address they will be sent an email.
When logged out, Firefly III will not leak personal information. There is no identifying information in the pages that are available to guest users. The reset password option will tell users whether users have entered an existing email address or not. People who know or suspect what your email address is can use this feature to confirm it.
Firefly III has several options and features that can contact other servers on the internet.
- When registering, Firefly III uses the Have I Been Pwnd password API (v3) to verify if you're using a secure password. You can disable this when registering an account.
- Firefly III can optionally contact version.firefly-iii.org to check for new versions. This is a Linux machine hosted on Azure.
- Firefly III can optionally download and view mapdata generated by Mapbox.
- Firefly III can optionally use a user configurable Matomo installation to track user behavior on Firefly III. This is used on the demo site. Read more.
Otherwise, Firefly III contacts no outside servers and will not download JS libraries or fonts. Headers added to each page will prevent Firefly III from running outside scripts.
Firefly III stores all uploaded attachments unencrypted in the
/storage/upload directory. Users who have permissions to the file system will be able to get uploaded attachments for all users.
No encryption of data-at-rest is used. Use your operating system's disk encryption features for further protection of data-at-rest. For data-in-transit, see TLS below.
A public/private keypair is generated to be used for the signing of API keys (Personal Access Tokens and OAuth Clients). This keypair is stored under
/storage and has no further protection.
Logged in users can download an export of their data from the user interface (under
/export). On the command line, users can export data and store it in any directory writeable to the user using the
firefly-iii:export-data command. To use this command you'll need a special access token, which can be found under the
/profile page. This token is strictly personal.
Firefly III does not come with TLS enabled. This is up to you to setup. It does support it however. The Docker image can be protected using a reverse proxy setup, where the reverse proxy enables TLS. When self-hosting, this is up to you to configure.
Firefly III supports a SSL connection to the database, when using MySQL or PostgreSQL. This is disabled by default.
All secrets in use by Firefly III are stored in environment variables. These are offered to Firefly III by using actual environment variables (preferred), by using the
.env file or by using Docker's feature to share environment variables with Firefly III.
Firefly III supports the use of files for secrets (see the
.env.example file). Sensitive information used to run Firefly III should not be stored in plaintext. Check out Docker secrets.
XSRF and XSS
When you set the
APP_DEBUG environment variable to
true, Firefly III will leak an amazing amount of private data when it encounters a bug. This includes secrets and passwords.
Bugs may also appear (and thus leak sensitive information) on pages not protected by a user login. An example would be the password reset page: misconfigured email settings may expose sensitive information when Firefly III reports the issue through an error page.
By default Firefly III outputs its logs to
stdout and to a file in
/storage/logs. That means that users who have permission to read these files or permission to the Docker engine can trace the log files and extract personal information from them. You can set the
error to prevent the logging of most information or to
emergency to prevent the logging of any information. When using Docker, keep in mind that Apache2 will keep logging each http request.
Even logging just error information may leak data.
Security bugs and issues
If you find a security issue or problem with Firefly III, please refer to the Security Policy.