Anyone installing a TYPO3 extension gets almost no structured information about what it actually does. Which database tables does it create? Does it open outbound network connections? Does it override TYPO3 classes via XCLASS? Today, the only way to answer these questions is to read the source code, which rarely happens in practice.
The concept project typo3-capability-manifest proposes a different approach: each extension declares its actual capabilities in a standardised YAML file. CLI tools then generate manifests, verify declarations against the code, and calculate a Risk Score. The idea was inspired by Cloudflare's EmDash model for WordPress , which takes a similar approach in the WordPress ecosystem.
Table of Contents
Overview
Features in Detail
Installation
Conclusion
Overview
In principle, TYPO3 extensions can reach almost every part of a TYPO3 system: they can override classes (XCLASS) , register hooks and events, make network requests, and extend database schemas. This is by design and part of the extensibility that makes TYPO3 so flexible. But it also makes risk assessment hard.
typo3-capability-manifest tackles this through declaration: a Configuration/Capabilities.yaml file inside the extension describes the capabilities it actually uses. That declaration can then be checked automatically against the code. Any discrepancies, whether declared but not found or found but not declared, are reported as audit findings.
The project ships example manifests for the 20 most widely used TER extensions, which serve as a reference for the manifest structure.
This extension supports TYPO3 ^13.4 || ^14.0 and PHP ^8.2, so it is not limited to TYPO3 v14. Alpha status means the concept is fully worked out and the CLI commands work, but the manifest format may still change. Use in production at your own risk.
Features in Detail
Manifest Structure
A Configuration/Capabilities.yaml declares what an extension does:
| Capability Key | Meaning | Risk Weight |
|---|---|---|
| network:outbound:any | Arbitrary outbound HTTP/TCP connections | 5 |
| xclass:override | XCLASS override of TYPO3 classes | 4 |
| auth:provider | Custom Authentication Provider | 4 |
| database:write | Write access to database tables | 3 |
| database:read | Read access to database tables | 1 |
| subsystem:frontend | Uses TYPO3 frontend rendering | 0 |
The Risk Score is the weighted sum of all declared capabilities. Thresholds: 0–4 Low, 5–9 Medium, 10–14 High, 15+ Critical.
CLI Commands
| Command | Function |
|---|---|
| capability:generate | Analyses the extension code and generates a draft manifest |
| capability:verify | Verifies declaration against actual code; reports discrepancies |
| capability:audit | Complete audit report: DECLARED & VERIFIED / DETECTED BUT NOT DECLARED / DECLARED BUT NOT FOUND |
| capability:policy-check | Checks all installed extensions against the Site Capability Policy |
Site Capability Policy
In config/capability-policy.yaml, the project team defines which capabilities are permitted and what Risk Score is acceptable:
vendor/bin/typo3 capability:policy-check
# -> Output: which extensions violate the policyThe policy offers allow and deny lists for individual capabilities, plus a global max_risk_score. Extensions that exceed the threshold or declare forbidden capabilities are flagged as policy violations.
Roadmap
The project is at alpha stage. Planned additions include:
Backend Module
Composer Integration
composer require if an extension exceeds the policy thresholdsTER Integration
Installation
composer config repositories.typo3-capability-manifest vcs https://github.com/dirnbauer/typo3-capability-manifest.git
composer require webconsulting/typo3-capability-manifest:@devFrequently Asked Questions
Conclusion
typo3-capability-manifest is an early concept project, but it addresses a concrete problem: the lack of transparency over what installed TYPO3 extensions actually do. Declarative manifests, machine-readable Risk Scores, and policy-based checks could measurably simplify the security assessment of TYPO3 instances, provided the format becomes an established standard.
Cloudflare's EmDash model for WordPress shows that such an approach can win acceptance, and bringing it to TYPO3 is the logical next step.
The concept builds on Cloudflare's EmDash model . Thanks to the TYPO3 security community for their early feedback. The project is licensed under the GPL.