Miniflux Proxy Authentication Depends on the Header Path
Miniflux can use a local password, an OAuth provider, WebAuthn, or an authentication proxy. The proxy option is attractive for a reader service behind a central identity gateway. It also creates two paths that can diverge: the protected browser route and the API route used by clients.
One set of observations
On 2026-10-30, ZoomEye count-only queries used sub_type=all, page 1, and page size 1. app="Miniflux" returned 0. title="Miniflux" returned 3,696. Both queries completed successfully.
The zero app result does not prove there are no Miniflux instances. It shows that the selected application fingerprint did not match. The title result shows a visible product-name signal, not a list of confirmed installations or vulnerable hosts.
For an owned deployment, use DNS and service inventory to find the reader. Then verify how the browser and the mobile or automation clients authenticate.
Trusted proxy networks
Miniflux's configuration documentation includes a list of networks allowed to supply proxy authentication headers and forwarded address headers. That setting is part of the trust boundary. A proxy header is useful only when the direct listener cannot receive it from an untrusted client.
If the application is reachable on a public port, a client may send the same header name directly. The backend should reject that path or never see it. Network policy, bind addresses, and reverse-proxy rules all matter. Test from a host outside the trusted proxy network.
Use a header name and identity value that the proxy overwrites. Remove inbound client headers at the edge. Keep the proxy configuration under the same change control as the application's authentication settings.
Local authentication and API keys
Miniflux documentation now describes DISABLE_LOCAL_AUTH behavior that also affects API password authentication and password changes. When local authentication is disabled, an API client should use the supported token or OAuth path rather than relying on a username and password.
This can break an older integration that appeared to work through the web login. Inventory API clients, browser extensions, and automation scripts before the change. Test the token after a user is disabled and after a proxy identity mapping changes.
The release history is also a reminder to track application versions. A prior release note described an OAuth account-binding vulnerability, and another noted enforcement changes around local authentication. Those are not present-day claims about every deployment. They are reasons to keep an upgrade path and verify the supported authentication mode for the installed version.
A compact test matrix
- Browser through the proxy with a valid identity.
- Browser through the proxy with no identity.
- Direct request with a forged proxy header.
- API request with a valid token.
- API request after the token is revoked.
- A disabled local-login attempt.
Record the route, source network, response status, and resulting user. Do not include feed URLs or article content in a public report.
Monitoring
Alert on direct backend connections from unexpected networks and on repeated authentication failures with unusual header values. Review proxy identity changes and user-disable events together. A user removed from the identity provider should not remain able to use a long-lived API token.
The product title count is only a discovery input. The security property is a browser and API client reaching their intended identity paths while the raw backend listener remains unavailable.
Top comments (0)