Security-Header-Architektur für TYPO3

Alle Security Headers zentral verwalten: PSR-15 Middleware für Response-Header, csp.yaml für die Content Security Policy und .htaccess als Shared-Hosting-Fallback.

Headers prüfen Plattform entdecken

TYPO3 · Schritt für Schritt

Von Wolf-Agents Security Team · Aktualisiert: 27. März 2026

Drei Konfigurationswege für TYPO3

TYPO3 bietet im Gegensatz zu vielen anderen CMS drei unterschiedliche Wege zur Header-Konfiguration. Die Wahl hängt von Ihrer TYPO3-Version, dem Hosting und der gewünschten Flexibilität ab. Diese Anleitung zeigt die empfohlene Architektur: PSR-15 Middleware als primärer Weg, ergänzt durch die native csp.yaml für CSP.

Der Wolf-Agents Web Security Check prüft 166 Punkte in 8 Kategorien. Mit der hier gezeigten Architektur erreichen Sie eine Note A oder besser — alle Header werden zentral in einer Middleware verwaltet, ohne dass Sie einzelne TypoScript-Einträge pflegen müssen.

Allgemeine Einführung in die Header-Architektur

1 Schritt 1 von 4

PSR-15 Middleware erstellen

Die PSR-15 Middleware ist der sauberste Weg für alle Security Headers außer CSP. Sie hat volle Kontrolle über das Response-Objekt, funktioniert unabhängig vom Caching und ist testbar. Erstellen Sie die Middleware in Ihrem Site Package.

<?php
// packages/site_package/Classes/Middleware/SecurityHeaders.php

namespace Vendor\SitePackage\Middleware;

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;

class SecurityHeaders implements MiddlewareInterface
{
    public function process(
        ServerRequestInterface $request,
        RequestHandlerInterface $handler
    ): ResponseInterface {
        $response = $handler->handle($request);

        // --- HSTS (Kap. 02) ---
        $response = $response->withHeader(
            'Strict-Transport-Security',
            'max-age=31536000; includeSubDomains; preload'
        );

        // --- Permissions Policy (Kap. 04) ---
        $response = $response->withHeader(
            'Permissions-Policy',
            'camera=(), microphone=(), geolocation=(), payment=()'
        );

        // --- Clickjacking-Schutz (Kap. 05) ---
        $response = $response->withHeader(
            'X-Frame-Options', 'SAMEORIGIN'
        );

        // --- Referrer Policy (Kap. 06) ---
        $response = $response->withHeader(
            'Referrer-Policy',
            'strict-origin-when-cross-origin'
        );

        // --- MIME-Sniffing-Schutz (Kap. 07) ---
        $response = $response->withHeader(
            'X-Content-Type-Options', 'nosniff'
        );

        // --- Cross-Origin Headers (Kap. 08) ---
        $response = $response->withHeader(
            'Cross-Origin-Resource-Policy', 'same-origin'
        );
        $response = $response->withHeader(
            'Cross-Origin-Opener-Policy', 'same-origin'
        );

        // --- Origin Agent Cluster (Kap. 16) ---
        $response = $response->withHeader(
            'Origin-Agent-Cluster', '?1'
        );

        return $response;
    }
}

Warum PSR-15 statt TypoScript?

TypoScript-basierte Header (config.additionalHeaders) werden nur bei Seiten gesetzt, die durch TYPO3 gerendert werden. Statische Dateien, API-Endpoints und gecachte Seiten (EXT:staticfilecache) erhalten diese Header nicht. Die PSR-15 Middleware greift bei jedem Request.

2 Schritt 2 von 4

Middleware registrieren

Registrieren Sie die Middleware in Configuration/RequestMiddlewares.php. Sie wird nach dem Page Resolver ausgeführt, sodass alle TYPO3-internen Header bereits gesetzt sind und Ihre Middleware sie ergänzen oder überschreiben kann.

<?php
// packages/site_package/Configuration/RequestMiddlewares.php

return [
    'frontend' => [
        'vendor/security-headers' => [
            'target' => \Vendor\SitePackage\Middleware\SecurityHeaders::class,
            'after' => ['typo3/cms-frontend/page-resolver'],
        ],
    ],
];

Vergessen Sie nicht, nach dem Erstellen der Middleware den TYPO3-Cache zu leeren: vendor/bin/typo3 cache:flush. Ohne Cache-Flush wird die Middleware nicht erkannt.

3 Schritt 3 von 4

CSP über csp.yaml konfigurieren

Seit TYPO3 v12.3 wird die Content Security Policy separat über config/sites/[site]/csp.yaml verwaltet. TYPO3 generiert automatisch Nonces über 'nonce-proxy' und ersetzt diese in Fluid-Templates. CSP gehört nicht in die PSR-15 Middleware.

# config/sites/main/csp.yaml
inheritDefault: true
mutations:
  - mode: set
    directive: default-src
    sources:
      - "'self'"
  - mode: set
    directive: script-src
    sources:
      - "'self'"
      - "'nonce-proxy'"
  - mode: set
    directive: style-src
    sources:
      - "'self'"
      - "'unsafe-inline'"
reportingUrl: true

Ältere TYPO3-Versionen (vor v12.3)

Ohne natives CSP-System setzen Sie die Content Security Policy per config.additionalHeaders in TypoScript. Nonces sind dann nicht automatisch verfügbar — nutzen Sie stattdessen Hash-basierte CSP für statische Inline-Scripts.

4 Schritt 4 von 4

Verifizieren und Shared-Hosting-Fallback

Leeren Sie den TYPO3-Cache und prüfen Sie alle Header. Auf Shared Hosting ohne Zugriff auf die PHP-Ebene nutzen Sie die .htaccess als Fallback.

# Cache leeren
vendor/bin/typo3 cache:flush

# Header prüfen
curl -sI https://ihre-domain.de | grep -iE "strict|x-frame|x-content|referrer|permissions|cross-origin"

# .htaccess — Fallback für Shared Hosting
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Cross-Origin-Opener-Policy "same-origin"
    Header always set Cross-Origin-Resource-Policy "same-origin"
    Header always set Origin-Agent-Cluster "?1"
</IfModule>

Verwenden Sie nicht gleichzeitig PSR-15 Middleware und .htaccess für den gleichen Header. Doppelte Header führen zu unvorhersehbarem Verhalten. Entscheiden Sie sich für einen Konfigurationsweg pro Header.

Häufige Fehler bei TYPO3 Security Headers

Header werden nicht gesetzt

TYPO3-Cache nicht geleert nach Middleware-Erstellung. Lösung: vendor/bin/typo3 cache:flush ausführen.

staticfilecache ignoriert Header

EXT:staticfilecache liefert gecachte Seiten direkt über den Webserver — TYPO3-Middleware wird nicht ausgeführt. Lösung: Header zusätzlich in .htaccess setzen.

Extensions überschreiben Header

Manche Extensions setzen eigene Header. Prüfen Sie mit curl -sI auf doppelte Header und passen Sie die Middleware-Reihenfolge an.

CSP in Middleware statt csp.yaml

CSP gehört ab TYPO3 v12.3 in die csp.yaml — dort werden Nonces automatisch generiert. In der Middleware fehlt die Nonce-Integration.

Compliance-Relevanz

Eine konsolidierte Header-Architektur ist nicht nur Best Practice, sondern auch für Compliance relevant. PCI DSS 4.0 (Anforderung 6.4.3) fordert die Kontrolle aller auf der Zahlungsseite geladenen Scripts — eine korrekte CSP ist hier Pflicht. NIS2 verlangt technische Maßnahmen zur Cybersicherheit, wozu Security Headers gehören. Der Wolf-Agents Web Security Check dokumentiert Ihren Umsetzungsstand mit einem Prüfbericht.

Auch verfügbar für:

Nginx Apache WordPress Next.js Cloudflare Express Caddy Shopify Hetzner Laravel DrupalIONOSDemnächstAll-InklDemnächstShopware ContaoStratoDemnächstJoomla PHP Spring Boot

Wie steht Ihre Domain bei Implementierungs-Architektur?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo