Add an option to disable object sharing and its public proxy

[jiri-pejchal]

Silo Console lets authenticated users create time-limited links that allow recipients to download an object without signing in. By default, these links use a public Console endpoint that proxies the download from the configured Silo server.

The endpoint checks that the initial URL points to that server, but not that it is a genuine presigned object URL. It can therefore proxy unauthenticated GET requests to other paths on the server. No configuration option disables this behavior without disabling the entire Console UI.

In a deployment running with MINIO_PROMETHEUS_AUTH_TYPE=public, the demonstrated impact is access across a network boundary to internal metrics endpoints. This is not a demonstrated general SSRF. Redirects could broaden the reachable targets, but no anonymous redirect primitive has been demonstrated.

Observed behavior

The route is declared without authentication (security: [],swagger.yml:3200-3204):

/api/v1/download-shared-object/{encoded-url}

decodeMinIOStringURL base64-decodes the supplied URL and compares its host to CONSOLE_MINIO_SERVER. It does not inspect the path, the query string, or the presence of X-Amz-Signature. Endpoints requiring SigV4 still reject the request. The Console relays the body only when the final response is 200 OK. For other responses, it reveals only the upstream status code and status text.

Security-boundary bypass

MINIO_PROMETHEUS_AUTH_TYPE=public removes authentication from the metrics endpoints on the Silo S3 API port. The Console port is reachable externally. The proxy target is the loopback endpoint 127.0.0.1:9000, which is not.
The proxy therefore carries an anonymous external request to an endpoint that is otherwise reachable only from inside the pod.

The encoded path is the base64url form of http://127.0.0.1:9000/minio/metrics/v3/cluster/usage/buckets; adjust the scheme and port to the deployment's CONSOLE_MINIO_SERVER value.

  GET /api/v1/download-shared-object/aHR0cDovLzEyNy4wLjAuMTo5MDAwL21pbmlvL21ldHJpY3MvdjMvY2x1c3Rlci91c2FnZS9idWNrZXRz
  Host: <console-host>
  (no Authorization header, no session cookie)

  HTTP/1.1 200 OK
<Prometheus text exposition: one series per bucket, bucket
  names as label values, with object counts and sizes>

The same method reaches /minio/v2/metrics/cluster, which returns node names, drive count and the quorum and erasure layout.

Why deployment-side mitigation fails

• Creating a share link through the Console requires authentication, but calling the proxy endpoint does not. Because callers can construct proxy URLs themselves, restricting share-link creation does not prevent anonymous use of the proxy.
• CONSOLE_SHARE_MINIO_URL controls only the default format of generated share links. An authenticated user can select the other format for an individual link using toggle_url (api/user_objects.go:1074–1078). Neither setting disables or restricts the public proxy endpoint.
• The supported CONSOLE_* environment variables include no option to disable object sharing or the public proxy (api/consts.go:20–91).
• MINIO_BROWSER=off disables the entire embedded Console, including its UI. This is not a practical mitigation for deployments that require Console access.

Request

Would you consider a server-side option to disable object sharing? When set, it could reject share-link creation, reject requests to the public proxy, and hide the share controls in the UI.

As defense in depth, the HTTP client should reject redirects or apply the configured-host restriction to every redirect target. Merely requiring presigned-S3 query parameters would not be sufficient: an attacker could attach fake signing parameters to an otherwise public internal endpoint. A stronger design could authenticate the encoded proxy URL itself — for example, with a Console-generated MAC — or retain server-side state for issued share links. Silo would continue to validate the underlying S3 presigned request.

Version tested: Silo RELEASE.2026-09-03T13-18-01Z
Code: decodeMinIOStringURL, api/public_objects.go:45-113. The proxy behavior originates in MinIO Console commit ceee83f — "Use Console as proxy for share object logic" (#3284, April 2024).

[Vonng]

Thank you, @jiri-pejchal, for the detailed report, the reproducible metrics example, and the careful distinction between the demonstrated network-boundary bypass and hypothetical redirect abuse. We have credited you in the SILO contributor record, the English and Chinese README contributor lists, and the website.

The security fix has now been merged through PR #56: merge commit 60aa9492779a. The decision record below explains both the fix and why it does not add a sharing-disable environment variable.

What we confirmed

The original anonymous download handler checked only the initial backend host. It could request non-object paths on that server and followed redirects. With public metrics on an otherwise internal S3 listener, this exposed metrics through the externally reachable Console. Adding fake presigning parameters did not prevent that access because the metrics endpoint does not validate S3 signatures.

We did not demonstrate a bypass of S3 object authorization or administrative authentication. Redirect following was reproduced with an HTTP fixture; we did not establish an anonymously controllable redirect chain in a normal SILO deployment.

Final request boundary

The handler remains anonymous so recipients can use shared links without a Console account. Before making any backend request, it now restricts the target to object-content GETs:

Area	Accepted	Rejected
Destination	The configured S3 scheme, host and effective port	Other origins, user information, fragments and opaque URLs
Path	A valid bucket and nonempty object key	Root and bucket-only paths, minio / .minio.sys* system paths, and dot path components
Query	Signing and session parameters, versionId, partNumber, download response options, and non-routing parameters	Malformed query encoding and the non-download selectors acl, tagging, retention, legal-hold, attributes, uploadId, lambdaArn, torrent
Redirects	A direct backend response	Every 3xx ends with 502; no redirect is followed and no Location is relayed

Validation does not rewrite the original URL, normalize object keys as filesystem paths, or repeatedly decode them. This preserves signature bytes, encoded names and versioned downloads. Only the sharing HTTP client disables redirects, and client cancellation is propagated upstream. The production fix is confined to api/public_objects.go; the other changes provide regression tests, CI coverage and documentation.

S3 remains responsible for authorization. Public objects can still be downloaded without a signature when their bucket policy allows it; private objects require valid S3 authorization. The proxy adds no Console administrator credentials. The outer encoded URL is not itself authenticated as Console-issued: callers may construct one, but it must satisfy the same object-download boundary.

Why there is no new switch

During the September 12 implementation, we initially prototyped CONSOLE_SHARE_ENABLED=off, covering link creation, the anonymous endpoint and UI controls, including configuration propagation into embedded Console. We subsequently removed it after separating two requirements:

1. Correct the download proxy's access boundary whenever sharing is available.
2. Offer administrators a product-level ability to disable sharing altogether.

The first requirement is the security repair. It should apply by default, without requiring an operator to discover and configure a mitigation. A switch does not replace these checks when sharing is enabled, and adds configuration semantics, frontend/session state, embedder handling and additional test combinations. The second requirement is a separate product capability that we are not adopting as part of this resolution; this change does not implement complete sharing disablement. Even a Console-wide switch would not revoke native S3 presigned URLs already issued: their validity remains governed by S3 authorization and expiration.

CONSOLE_SHARE_MINIO_URL keeps its existing meaning: choosing the generated link format. It is not repurposed as a security control, and toggle_url cannot bypass the new proxy boundary. Changing metrics authentication alone also does not correct the proxy's request scope.

Requiring signature-shaped query fields would not solve the reported issue, as your report explains. Requiring signatures for otherwise public objects would unnecessarily remove supported behavior. A Console MAC or server-side link registry could establish a stricter “only links issued by Console” contract, but would introduce key/state lifecycle and compatibility costs that are not needed for this bounded object-download contract.

Compatibility and maintenance

Normal public, presigned, versioned and specially encoded object downloads are preserved. Using the share endpoint as a proxy for bucket listings or object subresources, or relying on backend download redirects, is no longer supported. The checks add local parsing and comparisons, with no extra S3/IAM calls, database, token store or whole-object buffering. When the maintained SILO router adds a query-selected object operation, its selector must be reviewed against this boundary and the regression tests.

Validation and delivery

• The required Console matrix and vulnerability checks passed at the final PR head 56dfe455ac2f before merge. A transient Yarn installation failure was rerun successfully; the required checks remained enforced.
• As a negative control, restoring the previous main handler caused 32 URL-scope subtests to fail and relayed a metrics fixture with HTTP 200 where the corrected handler returns 403. This was an isolated handler regression check, not a claim about a deployed system.
• Locally, API/package tests, focused race tests, Go lint, frontend type checking and formatting passed. Fresh binaries passed the real API and Chromium sharing checks in both deployment modes.
• A second fresh Server build, selecting the immutable module github.com/pgsty/silo-console v0.0.0-20260916034812-56dfe455ac2f through its normal go.mod and checksum verification, also passed both API/browser deployments.
• Server #209 passed all eight PR checks and merged as 3c26a8b0b5bd. It selects the corrected Console revision and adds the contributor credit. Server Go CI and vulnerability analysis passed before merge.
• The merged Console main commit also passed the full CI matrix and vulnerability checks. The merged Server main commit passed Go CI and vulnerability analysis as well.

The required CI matrix includes real API and browser sharing checks in both standalone and embedded SILO, using the Console checkout under test. These cover normal sharing, S3 authorization failures, public metrics rejection, versioned and encoded objects, and both generated link formats. HTTP fixtures separately verify that same-origin and cross-origin redirects receive no follow-up requests.

This is a merged source fix, not a claim that Console v2.4.0 or the September 3 Server release already contains it. Server main now selects the corrected Console revision, so embedded deployments can obtain it from a build containing Server georgmangold#209. Publishing new standalone Console and Server releases remains a separate delivery step; existing installations are not changed by these merges. We are resolving the security defect with the always-on boundary above, while explicitly recording that the proposed full-disable switch was not adopted.

User-facing behavior is documented in the Console reference. Thank you again for helping us make that boundary precise.

[jiri-pejchal]

Thank you for the fix! 👍