SiYuan versions before v3.7.4 contain an information disclosure vulnerability in the /api/storage/getOutlineStorage endpoint that performs no authorization checks. Attackers can retrieve outline state including heading identifiers for any document by supplying its identifier, even for documents forbidden to the requester.

Affected: Go: github.com/siyuan-note/siyuan/kernel

### Summary

`/api/storage/getOutlineStorage` is registered with `CheckAuth` only and performs no authorization of any kind. Given a document identifier it returns that document's stored outline state, regardless of the document's publish tier.

The two write endpoints for the same data, `setOutlineStorage` and `removeOutlineStorage`, both carry `CheckAdminRole` and `CheckReadonly`. Only the read path is unguarded.

### Details

**Routes.** `kernel/api/router.go:103` on master, `:108` on the development branch:

```go ginServer.Handle("POST", "/api/storage/getOutlineStorage", model.CheckAuth, getOutlineStorage) ginServer.Handle("POST", "/api/storage/setOutlineStorage", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, setOutlineStorage) ginServer.Handle("POST", "/api/storage/removeOutlineStorage", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, removeOutlineStorage) ```

**Handler.** `kernel/api/storage.go:466` on the development branch, `:469` on master, identical. It binds `docID` and calls `model.GetOutlineStorage(docID)`, which iterates the stored outline documents and returns the entry whose `DocID` matches. There is no filter function on this path at all: no `*gin.Context`, no publish-access check, no password check, no visibility check. The caller supplies the identifier and receives the payload.

**What is stored.** `type OutlineDoc { DocID string; Data map[string]any }`. The client writes it from `app/src/layout/dock/Outline.ts:742`:

```…