Gokapi shares files through a web interface and an API. The official documentation says API calls require an API key. The setup documentation also describes OIDC delegation, where an external identity provider can handle browser authentication while API calls continue to use Gokapi's key model.
That split is useful. It also means a deployment can look well protected in the browser while service integrations retain independent credentials.
Count-only evidence
On 10 November 2026, ZoomEye observations used sub_type=all, page 1, and page size 1. http.body="Gokapi" returned 121 matches. title="Gokapi" returned 8, and app="Gokapi" returned 0.
The selected query is the ZoomEye result for http.body="Gokapi". The larger body count does not prove there are 121 servers. It indicates pages whose content contains the product name. The small title and application counts show why a single field is a poor inventory strategy.
Inventory the API surface
For each integration, record:
the API key identifier and owner;
the operations the key can perform;
the files or groups it can reach;
the client host and network path;
creation, rotation, and expiry dates;
the person or team that can revoke it.
Do not use one key for every script. A key that can create, list, and delete files has more authority than a key that only uploads. If the application supports per-key permissions, test them with a denied operation. If it does not, compensate with network restrictions and a dedicated deployment.
Store keys outside the application repository. A Docker environment file, a CI variable, and a shell history file are all common leak locations. Use a secret manager and inject the key at runtime. Log the key identifier, never the full secret.
Review OIDC and internal authentication
When OIDC is enabled, record the issuer, client ID, redirect URI, and allowed groups. Test that a user outside the intended tenant is rejected. Check whether enabling OIDC disables local browser authentication while leaving API keys active. The review must cover both outcomes.
If internal accounts remain, define who can create them and how they are removed. The Gokapi setup documentation describes a login at /admin and an optional key-management page. Protect that route with a private network or an identity-aware proxy even when OIDC is enabled.
File lifecycle
A share can have a password, an expiry, and a download limit. Test each control independently. A password does not replace expiry, and an expiry does not prove the storage object was deleted. Check the storage backend after the application reports removal.
If cloud storage is used, separate the application's credentials from the users who read the bucket. Enable object versioning only when the retention policy accounts for deleted shares. Otherwise a deleted file may remain recoverable through an old version.
The practical review
Use 121 body matches as a starting point for ownership verification. For each confirmed instance, identify the admin route, OIDC configuration, API keys, storage backend, and retention policy. Ask whether the service is meant to be public.
Gokapi's split between browser identity and API keys is reasonable. The control only works when both paths are inventoried and revoked together. A well-protected admin page and an old integration key can coexist on the same deployment.