T09 · Insecure Skill Coding Practices
- Location
references/examples.md:39- Finding
Unauthenticated Unrestricted Logseq API Bridge
- Content
View full analysis
Vulnerability Details
File Location:
references/examples.md:39-56
Vulnerability Type: Unauthenticated dynamic API dispatch
Risk Level: HighVulnerable Code
javascript ### HTTP Bridge (for external scripts) If you need to call Logseq API from external Node.js scripts, create a bridge plugin: ```javascript // bridge-plugin/index.js import '@logseq/libs'; logseq.ready({ async call({ method, namespace, args }) { const proxy = logseq[namespace]; if (!proxy || !proxy[method]) { throw new Error(`Unknown method: ${namespace}.${method}`); } return await proxy[method](...args); } }).then(() => { // Listen on HTTP or expose IPC console.log('Bridge ready'); });Technical Analysis
The recommended bridge dynamically resolves both
namespaceandmethodfrom caller-controlled input and invokes the resulting Logseq API with caller-supplied arguments. It does not implement:- Authentication or session-token verification
- Authorization by operation or resource
- An explicit namespace and method allowlist
- Argument schema validation
- Origin or host validation
- Restrictions against destructive operations
- User confirmation for sensitive actions
Checking whether a namespace and method exist is not an authorization control. Consequently, an HTTP or IPC implementation based directly on this example could expose all APIs available to the plugin rather than only the minimal operations required by an automation task.
The documented API surface includes graph-wide content queries, page and block modification, page deletion, graph configuration changes, file enumeration, and Git commands. The relevant destructive and privileged capabilities are documented at
references/api-reference.md:323-327andreferences/api-reference.md:567-578.Attack Path
- A user follows the example and exposes the
callcallback through an HTTP or IPC endpoint. - The endpoint is reachable by an untrusted local process, a r ...[truncated 1454 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace dynamic namespace and method dispatch with a small, explicit allowlist of required operations.
- Bind any HTTP listener exclusively to a loopback interface unless remote access is an intentional and secured requirement.
- Require a cryptographically strong, per-installation or per-session authentication token and compare it using a constant-time mechanism.
- Enforce authorization separately from authentication. Deny page deletion, unrestricted database queries, configuration changes, file enumeration, and Git operations by default.
- Validate every request against strict schemas, including method names, identifier formats, argument types, lengths, and nesting depth.
- Apply browser-origin protections where relevant, including a restrictive CORS policy and validation of
OriginandHostheaders. Do not treat CORS alone as authentication. - Require explicit user confirmation for destructive or high-impact write operations.
- Add request-size limits, timeouts, rate limits, and audit logging that excludes sensitive graph content and credentials.
- Return generic errors to remote callers rather than internal object details.
- Document the bridge's trust boundary and provide a secure, complete server implementation instead of leaving transport and access controls unspecified.
A safer design should expose named handlers such as
getBlockorinsertBlockand map each handler to one fixed API call after authorization and schema validation, rather than evaluatinglogseq[namespace][method]from request data.