Summary
SiYuan contains an authorization weakness in the /api/export/preview endpoint that may allow public readers to view data from password-protected or publication-disabled database rows.
When a public document embeds a database view, an attacker may obtain primary-key text and cell values from rows that should not be exposed.
Affected context
The issue may occur in SiYuan deployments where:
- A document is publicly readable
- The document embeds a database view
- The database contains password-protected or publication-disabled rows
- The export preview endpoint does not enforce the same visibility restrictions as the underlying database
Exposure depends on how public publishing, database permissions, and preview processing are configured.
Exploit preconditions
- Attack surface: The
/api/export/previewapplication endpoint - Required access: Ability to access a publicly available document containing a database view
- Trigger point: Generation of an export preview for the public document
- Why exploitation is possible: Authorization checks for protected or unpublished database rows may not be consistently applied during preview generation
Why this happens
The underlying bug is an authorization enforcement failure mapped to CWE-862: Missing Authorization.
The preview-processing path appears to rely on document visibility while failing to independently verify row-level protections and publication status. This creates an insecure pattern in which data is included in an export-related response without confirming that the requesting user is authorized to view each referenced row or cell.
Potential impact
- Unauthorized disclosure of protected database rows
- Exposure of primary-key text and cell values
- Leakage of information from unpublished content
- Privacy, confidentiality, or competitive-impact consequences
- Increased risk of correlating exposed records with other public data
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every data access boundary, including export and preview features.
Common defensive patterns include:
- Applying row-level and field-level authorization checks during preview generation
- Treating publication status and password protection as mandatory access controls
- Returning only data that the requesting principal is explicitly allowed to view
- Using secure-by-default behavior that excludes protected rows from public exports
- Reducing trust in document visibility as a substitute for database authorization
- Avoiding disclosure of identifiers or cell values when authorization cannot be established
- Applying least privilege to service accounts and preview-generation components
- Testing access-control behavior consistently across normal views, exports, previews, and APIs
How teams detect issues like this
High-level detection approaches include:
- Static analysis and code review for export or preview handlers that access database records without centralized authorization checks
- Review signals such as filtering only by document visibility while omitting row-level publication or password conditions
- Automated tests that compare normal database access decisions with export-preview responses
- Dynamic testing using public documents containing protected and unpublished records
- Monitoring preview endpoints for unusual requests involving public documents with embedded database views
- Policy enforcement requiring authorization checks before serialized data enters export or rendering pipelines
