Security

Because Firefly III stores personal financial information it's important to know how Firefly III is secured, and how it's not.

Database

The database is not encrypted, and data in the tables of the database is readable for humans. 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, ensure that the database can't be connected to from the web, but only from localhost. Preferably, 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 ensure 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.

Personal information

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 not confirm if accounts exist.

Privacy

Firefly III has several options and features that 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.
• Firefly III can optionally download currency exchange rate information an Azure bucket.

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.

Storage

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.

Encryption

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. There are instructions in the .env.example to provide your own key material.

Export

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.

TLS

Firefly III does not come with TLS enabled. This is up to you to set up. 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 an SSL connection to the database, when using MySQL or PostgreSQL. This is disabled by default.

Docker secrets

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

Each form in Firefly III is protected by a token preventing cross site request forging. All javascript on Firefly III pages must also be called with a special token to prevent cross-site scripting.

Firefly III is thus prevented from executing unexpected Javascript in case of newly discovered SQL injection or forgotten escaping.

Debug

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.

Logging

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 APP_LOG_LEVEL to 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

Other stuff

If you have more questions regarding the security of Firefly III, or how to secure your Firefly III installation, please contact me directly or open a ticket on GitHub.