REST-APIs in TYPO3 sind mächtig — und entsprechend schützenswert. Wer sg_apicore einsetzt, um Ressourcen bereitzustellen, muss sicherstellen, dass nicht versehentlich sensible Endpunkte ohne Prüfung erreichbar werden. Die api-capability-bridge schließt diese Lücke, indem sie die Ressourcen-Registrierung an eine deklarative Policy-Prüfung knüpft: Nur wer die Policy besteht, wird überhaupt registriert.
Grundlage dafür ist das webconsulting/typo3-capability-manifest, das pro Extension ein maschinenlesbares Manifest mit Risk-Level-Klassifizierungen bereitstellt. Die Bridge verbindet beide Welten und macht den Sicherheitsstatus von REST-Ressourcen zur ersten Hürde — bevor eine einzige HTTP-Anfrage beantwortet wird.
Inhaltsverzeichnis
Überblick
Funktionen im Detail
Installation
Fazit
Überblick
Die api-capability-bridge ist eine TYPO3-Extension im Alpha-Stadium, die das REST-API-Framework sg_apicore um einen vorgeschalteten Policy-Layer erweitert. Statt Ressourcen pauschal zu registrieren, liest die Bridge beim Systemstart config/capability-policy.yaml ein und prüft jede konfigurierte Ressource gegen das zugehörige Capability-Manifest. Nur Ressourcen, die diese Prüfung bestehen, werden tatsächlich als REST-Endpunkte verfügbar gemacht.
Das Capability-Manifest — bereitgestellt durch webconsulting/typo3-capability-manifest — klassifiziert jede Ressource nach ihrem Risk Level: low, medium, high oder critical. Die Policy-YAML kann je Ressource einen Mindest-Risk-Level vorschreiben oder über das Flag policy.require_manifest sicherstellen, dass Ressourcen ohne Manifest überhaupt nicht registriert werden — ein harter Stopp, kein stilles Durchlassen.
Die Extension bringt mit dem BackendBearerOpaqueTokenProvider eine eigene Authentifizierungsschicht mit: Opake Bearer-Tokens (SHA-256-gehasht) werden in tx_apicore_token gespeichert und Backend-Usern zugeordnet. Per X-TYPO3-Workspace-Header ist ein Workspace-Wechsel pro Request möglich — relevant für Redaktionsworkflows mit TYPO3-Workspaces.
Diese Extension setzt TYPO3 ^14.3 (14.3.0–14.9.99) und PHP ^8.3 voraus. Außerdem werden sgalinski/sg-apicore ^1.20 sowie webconsulting/typo3-capability-manifest ^1.0 benötigt. Die Extension befindet sich im Alpha-Status — produktiver Einsatz sollte sorgfältig abgewogen werden.
OpenAPI als Kontrollpunkt: Nach der Capability-Prüfung erscheinen nur freigegebene Routen in der Swagger UI; die Spezifikation bleibt damit nah an der Policy.
Funktionen im Detail
| Funktion | Nutzen |
|---|---|
| config/capability-policy.yaml | Zentrale Konfiguration: Welche sg_apicore-Ressourcen werden mit welchen Versionen und Security-Anforderungen registriert? api_definitions-Block erlaubt benannte API-Gruppen. |
| Capability-Check per Ressource | Jede Ressource wird gegen ihr Capability-Manifest geprüft (db-705). Risk Level low/medium/high/critical kann pro Ressource als Mindestanforderung erzwungen werden. |
| policy.require_manifest | Blockt Ressourcen ohne Capability-Manifest vollständig. Kein stilles Durchlassen bei fehlender Dokumentation — konservative Grundhaltung. |
| NewsStudioController | REST-Endpunkte für News-CRUD, TCA-generiertes Schema, Datei- und Bild-Upload, workspace-bewusstes Publizieren sowie Relationssuche — scope-geschützt (news:read, news:write). |
| BackendBearerOpaqueTokenProvider | Ordnet opake Bearer-Tokens (SHA-256) Backend-Usern zu. Workspace-Wechsel per X-TYPO3-Workspace-Header. Erweitert tx_apicore_token-TCA. |
| api_definitions-Block | Registriert benannte APIs mit Versionen und Security-Konfiguration zentral in der Policy-YAML — übersichtlich und versionierbar. |
Der NewsStudioController ist die bisher vollständigste Referenzimplementierung einer policy-gesteuerten Ressource: Er bietet News-CRUD-Operationen inkl. Datei- und Bild-Upload über die TYPO3 FAL-Schicht, workspace-bewusstes Publizieren und eine Relationssuche — scope-geschützt mit news:read bzw. news:write. Eigene Ressourcen lassen sich nach demselben Muster entwickeln.
Die Bearer-Token-Authentifizierung wurde bewusst einfach gehalten: Ein opaker Token wird im Backend angelegt, SHA-256-gehasht in tx_apicore_token gespeichert und bei eingehenden Requests gegen die Datenbank geprüft. Das bindet an TYPO3s Backend-Authentifizierungsinfrastruktur an, ohne eigene Session-Mechanismen einzuführen.
Installation
composer config repositories.api-capability-bridge vcs https://github.com/dirnbauer/api-capability-bridge.git
composer require webconsulting/api-capability-bridge:@alphaHäufige Fragen
Fazit
Die api-capability-bridge verfolgt einen konservativen Ansatz: REST-Ressourcen werden erst registriert, wenn sie eine explizite Policy-Prüfung bestehen. Das erhöht den Aufwand bei der Erstkonfiguration, macht dafür den Sicherheitsstatus von APIs deklarativ und versionierbar. Für Teams, die sg_apicore produktiv einsetzen und Compliance- oder Audit-Anforderungen erfüllen müssen, lohnt sich die Evaluierung — trotz des Alpha-Status.
Wer sich für die Grundlagen des Capability-Manifest-Konzepts interessiert, findet eine ausführlichere Einführung im Artikel /blog/typo3-capability-manifest.
Die Extension baut auf sg_apicore von sgalinski auf. Dank an das sgalinski-Team für die offene Architektur. Die Extension steht unter der GPL.