Directus presents a database as an API and an administration interface. A public deployment may expose a website, a login screen, a custom application, or the Directus Studio. The presence of the product does not show which collections are public or which fields a role can read. A useful review moves from a product candidate to the access policy for each collection.

A count-only ZoomEye measurement on 2026-10-29 returned 12,358 matches for app="Directus" and 1,254 for title="Directus". Both used sub_type=all, page 1, and page size 1. The application fingerprint is larger and selected. The figures are observed matches, not public collections, exposed records, or vulnerable deployments.

Understand the public role

Directus access control documentation describes roles and policies that govern create, read, update, delete, and share actions. The public role defines access for unauthenticated requests and for users without a role. Item permissions and field permissions are separate from the ability to reach the API. A role may see an item identifier while being denied the fields that contain the sensitive data.

Review the public role first. If it is intentionally used for a public website, list the collections and operations it needs and deny everything else. Check the API filters and field selections that a client can submit. Review dynamic variables and presets that could derive a tenant or user identifier from a request. A rule that trusts a client-provided owner field can turn a correct-looking permission into object-level access to another user's data.

Field-level permissions deserve the same attention. An item endpoint that returns a field by default can expose data even when the UI does not display it. Inspect the API response and the generated OpenAPI or schema view. Verify relationship fields and nested collections, because reading an item can traverse linked records if the policy allows it.

Separate Studio from public API routes

The Directus Studio is a management surface. It should be behind an identity provider, a network boundary, or both. The public API may need to remain reachable for a website or partner integration. Use separate hostnames or routes for the administration UI and the API, and apply authentication at the correct layer. A reverse proxy rule that requires login for the whole domain may break a public site, while a rule that exposes the whole domain may expose the Studio.

Review token lifetimes and the access tokens used by integrations. A token with administrator scope should not be embedded in a browser application or a CI job that only needs to read one collection. Test revocation by changing a policy or deleting a token, then confirm the cached client fails within the documented window.

The application fingerprint result is much larger than the title result. This shows that field choice affects the population being measured. It does not mean that every app match is an active Directus API. A proxy, custom response, or copied interface can influence the fingerprint. Confirm the candidate through an owned domain or a verified product route before reporting it as an asset.

Build a policy test matrix

For each public or partner-facing collection, test anonymous read, authenticated user read, cross-tenant read, field-level redaction, create, update, and delete. Use two users with different roles. Confirm that a list endpoint applies the same policy as a direct item request. Check the error response for information leakage, and log only identifiers and decisions.

Then test the Studio path separately. An operator should be able to sign in through the approved identity provider, while a deactivated user should lose access. If SCIM or a group mapping is used, verify that removing a group changes the effective policy. Review audit records for policy changes and unusual bulk reads.

Directus discovery becomes actionable when the owner knows which routes are public, which role serves them, and which collections and fields that role can access. The count helps find candidates. The permission matrix determines whether the API is doing only the work the organization intended.

References