DEV Community

StarkMan
StarkMan

Posted on

wger API keys connect fitness records to long-lived access

#zoomeye #zoomeye08wger

wger API keys connect fitness records to long-lived access

wger is a self-hosted fitness, workout, nutrition, and body-metric tracker with multi-user and gym-management features. Its data is personal, and its API is designed for mobile and third-party integrations. A public instance can therefore carry both health records and long-lived access material.

Observation

At 08:42 on November 4, 2026 (UTC+8), a count-only ZoomEye SDK query with sub_type=all, page 1, and pagesize 1 returned zero application matches for app="wger" and 213 title matches for title="wger". The title result may include project pages or instances with a different fingerprint. It is not a confirmed count of exposed health records.

API and account boundary

The API documentation says the REST API is served under /api/v2/ and that users can mint a long-lived refresh token from the web application's API-key page. It also describes login and two-factor authentication endpoints. That design is convenient for mobile clients, but it means a token can outlive the browser session that created it.

A review should separate public content from personal data. Exercise and ingredient catalogs may be intentionally shared, while routines, body measurements, and gym membership records should require an owner and a specific access policy. Test whether a normal user can read another user's records by changing an object identifier. If the API supports synchronization or OAuth, review the client registration and redirect rules as well.

The 2FA support and API key process should be checked together. A user who enables 2FA still needs a clear way to revoke an old refresh token. An administrator should know which clients are active and whether a disabled account remains able to use a token until it expires.

Review controls

Recommended checks include:

  • Inventory API keys and active refresh tokens.
  • Test object-level access with two non-administrator accounts.
  • Confirm that account disablement revokes or blocks token use.
  • Review gym, trainer, and member role assignments.
  • Check whether logs retain health data or authorization headers.
  • Verify backup encryption and retention for the database.

The public-facing login page and the API are separate surfaces. A homepage that looks ordinary can still expose a mobile API or an unauthenticated catalog endpoint. Enumerate the routes in the deployed version rather than assuming the web UI represents the whole service.

The 213 title matches are a useful queue for ownership checks and for monitoring changes over time. They do not establish vulnerability or unauthorized exposure. The actionable result is a ledger that connects each instance to its operator, authentication mode, API clients, data-retention policy, and revocation path.

For a sensitive application like wger, the safest statement is also the most useful: an indexed title is a prompt to verify the service boundary, not proof that personal records are public.

References

Top comments (0)