RomM exposure needs permission-group and client-token review

RomM is a self-hosted game library with users, permission groups, ROM metadata, saves, devices, and client API tokens. It is often deployed for a household, which can make a friendly sharing model feel less sensitive than a business application. The service can still contain account records, personal save data, device tokens, and uploaded files.

On 9 November 2026 at 08:50 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 1,269 assets for title="RomM" && http.body="RomM". The title query returned 1,389, the body query returned 17,859, and the application fingerprint returned zero. The title-and-body intersection is the conservative measurement.

The query is reproducible through the selected ZoomEye search.

The first user is an administrator

RomM documentation says the first user created during setup is always an administrator. Everyone after that is a regular user whose access comes from a permission group and any overrides. The first-login process is therefore a privileged provisioning event.

Test the setup flow before the instance is exposed. Confirm that the first administrator has a unique password, MFA if available, and a recovery owner. Do not let a shared household account become the only administrator. Review the process for deleting or rotating the first account if the person who installed the service leaves.

Permission groups are a matrix over entity types and actions. A group can grant read, write, or delete on platforms, ROMs, collections, and firmware. Per-user overrides can add a one-off grant. A hidden entity can stay hidden even when the user has a read grant.

Client tokens can be narrower than the user

RomM documentation says each user can issue up to 25 Client API Tokens. A token carries a subset of the owning user's scopes. The token is intended for companion apps and scripts, and the token is shown only once at creation.

Review each token's scopes and expiry. A token with roms.write can change metadata. A token with users.write is administrative. A token with no expiry remains usable until it is revoked. Delete tokens for retired devices and rotate a token after a device is lost.

The API supports session cookies, HTTP Basic, OAuth2 bearer, and client tokens. A route's required scope is part of the API contract. Test the same object with a narrow token and an administrator session. A token that cannot open the settings page should also fail the corresponding API call.

OIDC roles and kiosk mode change the boundary

RomM supports OIDC login and role mapping. The troubleshooting documentation describes role claim settings and a failure where a new user has no mapped application role. A login that fails closed is preferable to an account that is silently assigned administrator access.

The authentication documentation also describes kiosk mode as unauthenticated read-only access. Kiosk mode can be useful for a public demo, but it should only be enabled when the network cannot reach the instance directly or a reverse proxy enforces the intended boundary. A kiosk instance is not a private library.

Test the OIDC group mapping with an ordinary user, an administrator, and a user who is removed from the identity provider. Confirm how quickly the local session and client tokens stop working.

A practical review for an owned host

Create a test user in a narrow permission group. Attempt to browse platforms, edit a ROM, delete a collection, read a hidden entity, and create a client token. Then create a token with only the scopes the companion app needs and repeat the same operations.

Review the public routes, OIDC settings, kiosk flag, and token inventory together. Check the reverse proxy and CORS configuration. A wildcard CORS origin with credentials is not appropriate for a cookie-authenticated browser session.

The 1,269 matches are an inventory, not proof that every RomM instance is public. For each owned deployment, compare the first administrator, permission groups, hidden entities, token scopes, OIDC mappings, and kiosk mode. RomM's scope model is useful when the effective grants are tested instead of inferred from a role name.

References

• RomM documentation, Users and roles
• RomM documentation, Authentication
• RomM documentation, Client API tokens
• RomM documentation, API authentication