ContentLIBRE — home

SECURITY & OPERATIONS

Clear boundaries.
Deliberate deployment.

A guarded request boundary is one part of a secure deployment—not a substitute for credentials, network controls and an assembly reviewed for its environment.

Review the local setup guide Check project status

Different controls. Different responsibilities.

Admission gate

The gate refuses traffic when required boundary components are missing. Its hardened profile also refuses component-reported production blockers.

CORS and CSRF

CORS governs browser cross-origin grants; it is not authorization. CSRF controls protect writes that can carry browser-replayed credentials.

Anonymous request budget

Rate and concurrency limits bound uncredentialed requests. This is an abuse boundary, not a substitute for identity or application permissions.

Serialization guard

Generic node serialization is refused to anonymous callers, while intentionally rendered pages and real files can remain readable.

Caller identity

Typed API operations use the caller’s resolver. A public DTO must be intentionally shaped for publication, not copied from a management response.

Provisioning controls

File-drop channels can install running code. The documented hardened lock refuses traffic while the file installer is active; it does not disable that installer.

The boundary, in order.

The request boundary in order: admission gate, host classification, anonymous budget, CORS and CSRF, then Sling and the repository permissions that actually decide.
Each control has one job. None of them replaces the repository permission that decides whether a caller may read or write a node.

OPERATOR CHECKLIST

Before a deployment goes public.

  1. Replace development credentials and origins

    Configure the administrator credential and review the CORS allowlist. Keep credentials and signing secrets out of feature files, logs and examples.

  2. Review the network and ingress boundary

    Constrain the origin listener, terminate TLS and validate proxy-header handling for the selected deployment. A localhost URL is not proof of a loopback-only listener.

  3. Remove unnecessary administrative channels

    Review console access, JCR installation and file installation in the actual aggregate. Rebuild and boot-test dependency changes; dropping a feature is not automatically a safe assembly.

  4. Use hardened mode—and verify more than the mode

    The gate only reports what its components can observe. Test access policy, service identities, backups, restore, monitoring and the organization’s patch process separately.

Liveness is not readiness.

The documented /health/live route remains available when the admission gate is closed. That helps an operator distinguish a running process that deliberately refuses traffic from a process that is no longer responsive. It is not a statement that every service is ready.

Reporting a potential vulnerability.

A verified private reporting route has not been published yet. The project owner must publish and test that route before launch. Do not post exploit details, credentials or sensitive deployment information to a public issue. This page does not claim a response-time commitment.

Understand the foundation before deployment.

Start with the documented architecture and the boundaries of the selected release.

Read the architecture