Self-hosted Firefly III can rely on database-backed login, personal access tokens, OAuth clients, or a reverse proxy that supplies a remote user. The proxy option can fit an environment that already has a central identity provider. It can also turn a header into the most important authentication asset on the host.

What the application expects

Firefly III's remote user guard is documented as a mode in which the web server passes an identity header. The documentation warns that Firefly III performs no validity checks on the header or its contents. The application treats the proxy as the authenticator.

That design has a clear prerequisite. Every request must pass through the proxy, and the proxy must remove any client-supplied header with the configured name before adding its own. The backend listener must not be reachable directly by users or by workloads that can set arbitrary headers. If an application container is published on a second port, the proxy can be correct while the direct path bypasses it.

The header name should also be unusual enough to avoid accidental collision with another middleware. Firefly III exposes an AUTHENTICATION_GUARD_HEADER setting for the PHP header name. Change it only with a coordinated proxy and application deployment, then test the effective header from both paths.

A bounded observation

On 2026-10-30, ZoomEye count-only queries were run with sub_type=all, page 1, and page size 1. app="Firefly III" returned 2 matches. title="Firefly III" returned 3,725 matches. These are separate observations of asset fingerprints, not a claim that 3,725 instances are reachable or vulnerable. The app query is narrow; the title query may include login pages and other pages that present the product name.

The difference is a reminder to inspect the matching query rather than treating one product count as a complete census. A title match offers a presence signal, without evidence that the remote-user guard, API, or a particular version is exposed.

Test the trust chain

Use a disposable deployment with the same proxy and application containers. Send a request with a forged remote-user header directly to the backend. It should fail or be unreachable. Send the same request through the proxy and confirm that the proxy overwrites the value. Repeat with a missing header, an empty header, and a header with an unexpected user.

Inspect the proxy logs and the application logs together. The useful record connects a request to the proxy's authentication decision and the backend's resulting user identity. A successful page load without that correlation does not prove the header was supplied by the proxy.

Review the Firefly III token and OAuth pages as well. Remote user authentication and API tokens have different delivery paths. If the application cannot issue tokens in the current guard mode, operators may be tempted to add a broad workaround. Document the supported path for the installed version instead of weakening the header boundary.

Operational checks

  1. 1.

    List every listener for the Firefly III service.

  2. 2.

    Confirm that only the proxy network can reach the backend.

  3. 3.

    Remove inbound identity headers at the edge.

  4. 4.

    Test forged, missing, and authenticated headers.

  5. 5.

    Restrict proxy configuration changes to a small owner group.

  6. 6.

    Log the user mapping without logging tokens or financial records.

When an identity header is trusted, the proxy becomes part of the application's login code. Treat a configuration drift there as a security change, not as a routine web-server edit.

References