Summary
SiYuan before v3.7.3 exposes rendered content from publish-forbidden documents via backlink content APIs that do not correctly enforce publish-access filters.
A reader in publish mode, including anonymous users when Basic Auth is disabled, can query these endpoints with hidden document IDs to retrieve DOM content and probe whether specific blocks are referenced.
Affected context
This vulnerability arises in SiYuan instances that use the publish feature to selectively expose documents over HTTP.
Specifically, it affects deployments where:
- Documents are marked as publish-forbidden or otherwise hidden from public readers
- Backlink list endpoints correctly filter hidden documents, but content endpoints are still reachable
- The publish interface is available to authenticated or anonymous readers, and Basic Auth protections may be disabled or permissive
In these environments, the /api/ref/getBacklinkDoc and /api/ref/getBackmentionDoc endpoints can inadvertently serve content from documents that were intended to remain unpublished.
Exploit preconditions
- Attack surface: HTTP API endpoints
/api/ref/getBacklinkDocand/api/ref/getBackmentionDocexposed through the publish interface. - Required access: Ability to access the publish-mode reader interface; this can include anonymous access when publish Basic Auth is disabled.
- Trigger point: Directly calling the affected endpoints with the ID of a publish-forbidden document or target block.
- Why exploitation is possible: These content endpoints rely only on a general
CheckAuthgate and fail to apply the same publish-access filters used by the backlink list endpoints, allowing unauthorized users to receive rendered DOM content and reference-existence responses.
Why this happens
The underlying issue is an inconsistent authorization strategy between related API endpoints.
While the backlink list endpoints correctly enforce publish-access filters to hide forbidden documents, the corresponding content endpoints only perform a coarse authentication check and do not reapply or inherit the same fine-grained publish access rules.
This maps to CWE-862: Missing Authorization, where sensitive operations are exposed without the necessary authorization checks, leading to unintended disclosure of private document content and enabling oracle-style queries about references between blocks.
Potential impact
- Unauthorized readers could obtain rendered DOM content from documents that were configured as publish-forbidden.
- Hidden or sensitive information stored in unpublished documents may be exposed to public or low-privilege users.
- Attackers can use the reference-existence oracle to infer relationships between blocks and documents, aiding content mapping or reconnaissance.
- Privacy expectations around selectively published content can be undermined, potentially violating organizational data-handling policies.
General mitigation guidance
Effective mitigation focuses on enforcing consistent authorization checks across all endpoints that expose document data.
Common defensive patterns include:
- Centralizing publish-access logic so both list and content APIs consume the same authorization decisions before returning data.
- Treating any endpoint that returns document content or metadata as sensitive, requiring explicit checks against document publish status and user capabilities.
- Designing API controllers to deny by default and only permit access when access filters explicitly allow the operation.
- Minimizing information returned from APIs used for internal linking or backlink introspection, so they do not reveal content or detailed relationships unless the caller is fully authorized.
- Aligning UI and API behavior so that hidden documents are consistently protected, regardless of how they are queried.
How teams detect issues like this
Organizations can detect similar missing-authorization issues through:
- Static analysis rules that flag controller or handler methods which call data-access layers without preceding authorization checks.
- Code review practices that trace all entry points for document content exposure and verify they depend on centralized access-control decisions.
- Security testing that compares UI-visible content with API responses, ensuring unpublished or hidden documents never leak via backend endpoints.
- Logging and monitoring of API calls to sensitive document endpoints, with alerts when unauthenticated or low-privilege principals access internal or unpublished IDs.
- Policy enforcement in CI/CD that requires security review for new or modified content-serving endpoints.
