[Security] Unauthenticated GET endpoints in OpenIM API - openimsdk/open-im-server

[geo-chen]

OpenIM Server Version

commit d16a617

Operating System and CPU Architecture

Linux (AMD)

Deployment Method

Docker Deployment

Bug Description and Steps to Reproduce

Reported via email on 25 May 2026 but did not get any response.

I found that GinParseToken in internal/api/router.go only checks the token header for POST requests. Any GET, DELETE, PUT, PATCH, or HEAD request falls through the middleware without authentication.

func GinParseToken(authClient *rpcli.AuthClient) gin.HandlerFunc {
    return func(c *gin.Context) {
        switch c.Request.Method {
        case http.MethodPost:
            // token check
        }
        // for any non-POST method, no check, no abort -> handler runs
    }
}

Three GET routes are exposed in the API server:

• /third/prometheus -> 302 redirect to the configured Grafana URL
• /prometheus_discovery/ -> leaks RPC service discovery (host:port per service, namespaces) for api, user, group, msg, friend, conversation, third, auth, push, msg_gateway, msg_transfer
• /object/*name -> reaches ThirdApi.ObjectRedirect, which calls third RPC AccessURL and 302-redirects to a presigned S3 URL for the named object. No ownership check on retrieve.

PoC against openim/openim-server:latest with default config:

Baseline (POST is blocked):
POST /user/get_users_info (no token) -> {"errCode":1001,"errMsg":"ArgsError"} (header must have token)

Auth bypass (GET is NOT blocked):
GET /third/prometheus -> HTTP/1.1 302 Found, Location: /third/
GET /prometheus_discovery/msg_gateway -> HTTP/1.1 200 OK, body: [{"targets":["172.19.0.8:38635"],"labels":{"namespace":"default"}}]
GET /object/probe -> HTTP/1.1 500 Internal Server Error (stack trace shows the call reaches ThirdApi.ObjectRedirect -> AccessURL — the auth middleware did not abort)

Impact: anyone on the network can enumerate the service mesh and download any object whose name they can guess or have previously observed. Uploads use names of the form /, and userIDs are not secrets, so deterministic suffixes (avatars, group icons, hash-deduplicated content) are reachable.

Suggested fix: drop the POST-only switch so the middleware enforces the token check on every request (or explicitly whitelist the three GET endpoints if they are intended public, and add ownership checks on ObjectRedirect).

Screenshots Link

No response

[dsx137]

Thanks for the report.

We have confirmed that the current GinParseToken middleware only enforces token validation for POST requests, so the listed GET endpoints can be reached without the normal API token check.

For the monitoring-related endpoints, this is not expected to be exposed directly to the public Internet. In a normal production deployment, Prometheus and Grafana traffic is expected to stay inside a trusted internal network, or to be protected by a reverse proxy / firewall / network ACL.

At this time we do not plan to change the default behavior of these monitoring endpoints immediately, because /prometheus_discovery/* is used by Prometheus HTTP service discovery and Prometheus does not use the OpenIM user token flow. Requiring the normal API token globally would break existing monitoring deployments.

The recommended mitigation is to restrict these routes at the reverse proxy layer. For example, with Nginx:

upstream openim_api {
    server 127.0.0.1:10002;
}

# Only allow Prometheus to access service discovery.
# Replace 10.0.1.20 with your Prometheus server IP.
location ^~ /prometheus_discovery/ {
    allow 10.0.1.20;
    allow 127.0.0.1;
    deny all;

    proxy_pass http://openim_api;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

# Protect the Grafana redirect entry.
# Option A: restrict to internal/admin networks.
location = /third/prometheus {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;

    proxy_pass http://openim_api;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

# Normal API traffic.
location / {
    proxy_pass http://openim_api;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}