REST APIs in TYPO3 are powerful, and that makes them well worth protecting. Anyone using sg_apicore to expose resources has to make sure sensitive endpoints don't inadvertently become accessible without verification. The api-capability-bridge closes this gap by tying resource registration to a declarative policy check: only resources that pass the policy are registered at all.
The foundation for this is webconsulting/typo3-capability-manifest, which provides a machine-readable manifest with risk-level classifications per extension. The bridge joins the two worlds and makes the security status of REST resources the first hurdle, before a single HTTP request is even answered.
Table of Contents
Overview
Detailed Features
Installation
Conclusion
Overview
The api-capability-bridge is an alpha-stage TYPO3 extension that adds an upstream policy layer to the sg_apicore REST API framework. Instead of registering resources indiscriminately, the bridge reads config/capability-policy.yaml at system startup and checks each configured resource against its corresponding capability manifest. Only resources that pass this check are actually exposed as REST endpoints.
The capability manifest, provided by webconsulting/typo3-capability-manifest, classifies each resource by its risk level: low, medium, high, or critical. The policy YAML can mandate a minimum risk level per resource or, via the policy.require_manifest flag, ensure that resources without a manifest are not registered at all: a hard stop, not a silent bypass.
The extension introduces its own authentication layer with the BackendBearerOpaqueTokenProvider: opaque Bearer tokens (SHA-256 hashed) are stored in tx_apicore_token and assigned to backend users. The X-TYPO3-Workspace-Header allows a workspace switch per request, which is highly relevant for editorial workflows that use TYPO3 workspaces.
This extension requires TYPO3 ^14.3 (14.3.0–14.9.99) and PHP ^8.3. It also requires sgalinski/sg-apicore ^1.20 and webconsulting/typo3-capability-manifest ^1.0. The extension is currently in alpha status, so production use should be considered carefully.
Detailed Features
| Feature | Benefit |
|---|---|
| config/capability-policy.yaml | Central configuration: which sg_apicore resources are registered, with which versions and security requirements. The api_definitions block supports named API groups. |
| Capability check per resource | Each resource is verified against its capability manifest (db-705). A minimum risk level (low/medium/high/critical) can be enforced per resource. |
| policy.require_manifest | Completely blocks resources lacking a capability manifest. No silent bypasses for missing documentation — a conservative baseline approach. |
| NewsStudioController | REST endpoints for News CRUD, TCA-generated schema, file and image uploads, workspace-aware publishing, and relation lookups — scope-protected (news:read, news:write). |
| BackendBearerOpaqueTokenProvider | Assigns opaque Bearer tokens (SHA-256) to backend users. Workspace switching via X-TYPO3-Workspace-Header. Extends tx_apicore_token TCA. |
| api_definitions block | Registers named APIs with versions and security configurations centrally in the Policy YAML — well-structured and versionable. |
The NewsStudioController is the most comprehensive reference implementation of a policy-driven resource to date: it offers News CRUD operations, including file and image uploads via the TYPO3 FAL layer, workspace-aware publishing, and a relation lookup, all scope-protected with news:read or news:write. Custom resources can be built following the same pattern.
The Bearer token authentication was deliberately kept simple: an opaque token is generated in the backend, hashed with SHA-256, stored in tx_apicore_token, and verified against the database when requests come in. It integrates tightly with TYPO3's backend authentication infrastructure without introducing bespoke session mechanisms.
Installation
composer config repositories.api-capability-bridge vcs https://github.com/dirnbauer/api-capability-bridge.git
composer require webconsulting/api-capability-bridge:@alphaFrequently Asked Questions
Conclusion
The api-capability-bridge takes a conservative approach: REST resources are only registered if they pass an explicit policy check. This adds some upfront configuration effort, but in return it makes the security status of APIs declarative and versionable. For teams running sg_apicore in production that need to meet compliance or auditing requirements, this extension is well worth evaluating, despite its alpha status.
If you'd like to dig into the fundamentals of the capability manifest concept, you'll find a more detailed introduction in the article /blog/typo3-capability-manifest.
This extension builds upon sg_apicore by sgalinski. Thanks to the sgalinski team for their open architecture. The extension is licensed under the GPL.