Nuxeo API authentication is only the first permission decision

Nuxeo is a document platform with an API-oriented architecture. Its REST API can retrieve documents, inspect ACLs, run workflows, and expose custom endpoints. Authentication tells the server who is calling. The ACL attached to a document, folder, repository, or workflow determines what that identity can do.

On 2026-11-08, ZoomEye count-only observations returned 4 matches for app="Nuxeo", 186 for title="Nuxeo", and 28,973 for http.body="Nuxeo". The query used sub_type=all, page 1, and page size 1. The body count is far larger and can include documentation, examples, and unrelated pages. The application count is small, while the title count gives a broader product-level lead to validate.

Default ACLs and anonymous access

Nuxeo documentation describes a default ACL managed through the document interface and permissions that can be granted or denied. It also describes an anonymous user that can be referenced when a repository administrator gives certain folders or documents public access. Anonymous access is therefore an explicit grant, not an accidental HTTP state.

The practical question is which anonymous grants still exist. A public document may be intentional, but a folder that was made public for a temporary campaign can become a durable information leak. The ACL enricher and @acl adapter can help an authorized operator inspect inherited and explicit access decisions.

The REST authentication chain

Nuxeo's REST API uses an authentication chain that can include different providers. The chain configuration determines how a request becomes a principal. A reverse proxy that adds an identity header, a basic-auth endpoint, and a session cookie may all reach the same application through different paths.

Inventory each path. Confirm which headers are trusted, whether direct access to the application bypasses the proxy, and whether a test client can supply an identity header that the server accepts. A header that is safe only when stripped by the proxy is not an authentication control on a directly reachable listener.

What to review in the repository

List repositories and their public entry points. Identify top-level folders with broad read permissions, then inspect documents that are directly accessible through the REST path. Check inherited ACLs and any explicit deny or grant that changes the expected result.

Review principals, groups, and service accounts. An account used by a workflow may have access far beyond the worker's business purpose. Rotate credentials that are shared by multiple applications, and verify that removing a user from a group removes access to documents that the group granted.

A test plan

Choose two accounts: one that should have access and one that should not. Request the same document by ID, path, and search endpoint. Then request the ACL and confirm that the effective decision matches the intended policy. Repeat after revoking a permission to ensure that cached authorization state does not preserve access longer than policy permits.

Use the REST API's error behavior as evidence, not as the whole test. A 404 can mean the document is hidden, while a 403 can reveal that it exists. Record the result without assuming that an authentication success means the object was authorized.

Search: ZoomEye application fingerprint for Nuxeo

Nuxeo's API is designed to be programmable. The same flexibility makes an ACL inventory necessary. The product finding is useful only when paired with repository-level authorization evidence.

References

• Nuxeo, ACLs
• Nuxeo, Authentication
• Nuxeo, REST API endpoints