Faraday workspace scope is the real limit on API tokens

Faraday aggregates vulnerability findings across tools, assets, and workspaces. An API token can make imports and reporting repeatable, but the token's effective reach depends on the user's role and the workspaces assigned to that user. A token without that context is difficult to review.

On 9 November 2026 at 07:51 Asia/Shanghai, ZoomEye returned 197 matches for app="Faraday" with sub_type=all, page 1, and page size 1. The title query returned 933 and a body query returned 11,493. The app and title intersection returned zero, which is a useful reminder that a product-specific app value and a visible title are not interchangeable.

The selected query records the exact primary dork.

Roles and workspaces answer different questions

Faraday's user documentation describes role-based access control. It also describes workspace assignments and roles such as asset owner. The role determines what a user can do, while the workspace determines which findings and assets are in scope.

An API token is a credential for the user's account. It does not create a separate least-privilege identity unless the team creates one. A token copied from an administrator for a scanner integration can upload to any workspace the administrator can reach and may read more findings than the integration needs.

Faraday's API documentation uses session cookies or an API token in the Authorization header. Treat the token as a secret and store it outside report files, command history, and browser JavaScript. Limit the account to the workspace used by the integration and the smallest role that can perform the required import or read.

Test upload and read separately

Use a dedicated test workspace and two users: one with import authority and one with read-only access. Generate a token for each. Upload a benign report, query a vulnerability, and attempt to read a workspace the user is not assigned to. Confirm that the authorization failure is consistent across the REST API and the web interface.

Review the workspace owner and membership after people change teams. A user who can create a workspace may be able to invite members or change its visibility. Check whether an expired scan integration can still write to a live workspace.

Faraday's architecture uses a REST API, WebSocket notifications, PostgreSQL, Redis or RabbitMQ, and file storage. That distributed design is useful for automation, but it also means the integration path may touch more services than the web session. Keep network access between the server, workers, and data stores on an internal boundary.

Make the token lifecycle visible

Record a token's owner, workspace, role, creation date, last use, and retirement date. Rotate it when the integration changes or a person leaves. Remove tokens that do not have an owner.

Log imports with the workspace, source tool, record count, and result. If a scan report contains credentials or exploit evidence, do not log the full payload. Store the raw evidence with access controls and keep the API request as a reference.

The token should also fail closed if its workspace is removed or its role is reduced. Test that behavior rather than assuming the next scheduled import will fail cleanly. A successful upload to the wrong workspace is harder to undo than a rejected request.

A practical next step

Use the 197 app matches as an inventory lead. For owned Faraday deployments, review users, roles, workspace assignments, token ownership, and API exposure. Test one import token against an unrelated workspace and one read token against a write operation.

Faraday helps a security team turn scanner output into a shared record of risk. The token model should preserve that record's boundaries. A workspace-scoped identity with a short, documented lifecycle is more useful than a long-lived administrator key that nobody can trace.

References

• Faraday documentation, Users and Roles
• Faraday documentation, API Token
• Faraday documentation, API Server
• Faraday documentation, Application Architecture