A FreshRSS user may log in to the web interface while native apps use a separate API password. The two paths can have different exposure and logging behavior. Treating the API password as a copy of the web password obscures that boundary.
FreshRSS documents API access for mobile and native clients through the Google Reader API and the Fever API [1]. The mobile access guide instructs administrators to enable API access and users to set an API password in their profile [2]. The project's access-control documentation also describes form authentication, HTTP authentication, and an uncontrolled state with no authentication [3]. The deployment must choose one of those models deliberately.
Observed inventory
On 2026-11-07, a ZoomEye count-only probe with title="FreshRSS", sub_type=all, page 1, and pagesize 1 returned 11,840 matches [4]. The app probe returned 9,530 and the body query 26,651. These fields can surface valid installations and product references, but they do not prove that API access is enabled or that a password is weak.
Inventory the two login paths
Review API enablement, per-user API passwords, OpenID Connect or HTTP authentication, and any anonymous mode. A shared deployment should not allow one user's feed list, labels, or credentials to influence another user's session. Test a user who is disabled in the web interface but still has an API password, and a password change that does not invalidate an existing client.
Protect feed credentials
FreshRSS stores feed endpoints and may hold credentials or tokens used to fetch private sources. Those values belong to the same trust boundary as the user's session. Restrict server egress to expected destinations, separate administrative access from user accounts, and avoid placing API passwords in URLs or public dashboards. If a feed URL contains a secret, rotate it when the feed is changed.
Harden the web boundary
Use TLS, a supported authentication mode, and a reverse proxy that does not bypass the API path. Review the documented web-server instructions for protecting the API separately from the main interface [3]. Back up user and feed metadata with encryption and test restoration. Monitor repeated authentication failures and unusual feed additions.
Validate before acting
A ZoomEye title query can identify a product page for an authorized inventory check. It cannot show whether the instance is a test server, whether anonymous access is enabled, or whether a user has an API password. Confirm ownership and use approved configuration access before drawing an exposure conclusion.
FreshRSS connects users to external feeds and stores their reading state. The separate API path deserves its own lifecycle and test coverage.
References
- 1.
- 2.
- 3.
- 4.