NextPDF Symfony – Sicherheit und Betrieb

Auf einen Blick

Die Response-Helfer setzen einen fest definierten Satz von Sicherheits-Headern. Das asynchrone Message-DTO validiert den Ausgabepfad an zwei Stellen. Das Signieren ist optional und in der Pro-Stufe auf das hier dokumentierte Baseline-Profil beschränkt.

HTTP-Sicherheits-Header der Response

NextPDF\Symfony\Http\PdfResponse wendet denselben Header-Satz auf jede erzeugte Response an (Inline, Download und beide gestreamten Varianten). Die genauen Header, abgeglichen mit der Quell-Konstante:

Header	Wert
Cache-Control	private, max-age=0, must-revalidate
Pragma	public
X-Content-Type-Options	nosniff
X-Frame-Options	DENY
Content-Security-Policy	default-src 'none'
X-Robots-Tag	noindex, nofollow
Referrer-Policy	no-referrer

Sie reduzieren das Risiko von Content-Type-Sniffing, Framing, Indexierung und Referrer-Leaks bei erzeugten Dokumenten. Die gepufferten Varianten setzen zusätzlich Content-Type: application/pdf und Content-Length. Die gestreamten Varianten setzen den Content-Type, lassen aber Content-Length bewusst weg.

Der Header-Satz wird vom Bundle vorgegeben. Wenn Sie Header hinzufügen oder ändern möchten (zum Beispiel ein strengeres Cache-Control für authentifizierte Downloads), passen Sie die zurückgegebene Response in Ihrem Controller an, bevor Sie sie zurückgeben.

Content-Disposition und Behandlung von Dateinamen

PdfResponse erstellt den Header Content-Disposition defensiv, abgeglichen mit PdfResponseTest:

• Der Dateiname wird bereinigt; Pfadtrenner und Traversal-Sequenzen werden entfernt (ein Dateiname wie ../../../etc/passwd.pdf kann nicht ausbrechen).
• Eine .pdf-Endung wird angehängt, wenn sie fehlt; eine vorhandene Endung wird nicht dupliziert, auch nicht ein großgeschriebenes .PDF.
• Doppelte Anführungszeichen und Backslashes werden für die Quoted-String-Form maskiert.
• Für Nicht-ASCII-Dateinamen werden ein ASCII-Fallback und eine RFC-5987-Variante filename*=UTF-8'' gesetzt.
• Bei leerem Dateinamen wird auf document.pdf zurückgefallen.

Übergeben Sie einen von Benutzern beeinflussbaren Dateinamen erst nach Ihrer eigenen Autorisierungsprüfung auf Anwendungsebene; das Bundle bereinigt ihn für die Header-Sicherheit, nicht für die Zugriffskontrolle.

Asynchrone Validierung des Ausgabepfads

NextPDF\Symfony\Message\GeneratePdfMessage validiert den Ausgabepfad in seinem Konstruktor; NextPDF\Symfony\Message\GeneratePdfHandler validiert ihn zur Ausführungszeit vor dem Schreiben erneut. Bei der Konstruktion gelten folgende geprüfte Ablehnungsregeln:

• leerer Pfad oder ein Pfad, der ein Nullbyte enthält;
• ein Stream-Wrapper-Schema wie php://...;
• ein Traversal-Segment .. mit einem der Trenner / oder \;
• ein Pfad, der nicht auf .pdf endet (Groß-/Kleinschreibung ignoriert);
• eine builderClass, die syntaktisch kein gültiger Klassenname ist.

Die zweite Validierung im Handler ist wichtig, weil eine Message zwischen Dispatch und Verarbeitung in einer Queue verbleiben kann. Der Handler vertraut dem in der Queue gespeicherten Pfad nicht und wendet den Pfad-Guard vor dem Speichern erneut an. Führen Sie Worker unter einem Konto mit minimalen Dateisystemrechten aus, dessen Zugriff auf das vorgesehene Ausgabeverzeichnis beschränkt ist.

Grenze der Builder-Auflösung

GeneratePdfHandler löst Builder über einen PSR-11-Service-Locator auf, der nach Klassennamen indiziert ist, und lehnt alles ab, was kein PdfBuilderInterface ist. Weil der Locator nur registrierte Builder bereitstellt, kann eine durch Angreifer kontrollierte builderClass aus einer manipulierten Transport-Payload keine beliebige Klasse instanziieren. Unter PSR-11 schlägt das Auflösen einer ID fehl, wenn ein Container sie als nicht vorhanden meldet, statt stillschweigend etwas Unerwartetes zurückzugeben (PSR-11 §1.1.2). Registrieren Sie im Locator nur vertrauenswürdige Builder-Klassen.

Optionale Ausrichtung des digitalen Signierens

Digitales Signieren ist nicht Teil des Core-Bundles. Es wird nur aktiv, wenn nextpdf/premium (das die Pro-Stufe installiert) vorhanden ist und der Compiler-Pass die Pro-Signaturklassen erkennt. Mit installiertem Bundle und installierter Pro-Stufe ist die unterstützte und dokumentierte Signaturkonfiguration das Baseline-Profil B-B.

Der Konfigurationsknoten signature.level akzeptiert aus Gründen der Schema-Kompatibilität innerhalb der NextPDF-Konfigurationsfamilie weitere String-Werte. Die ausgelieferte und unterstützte Signaturfähigkeit dieses Bundles ist B-B. Signaturprofile jenseits von B-B, ihre Anforderungen und ihre betrieblichen Aspekte sind in der Dokumentation von NextPDF Premium beschrieben und werden hier bewusst nicht behandelt.

Betriebshinweise für den Signaturpfad B-B:

• Der Signierer wird nur registriert, wenn signature.enabled true ist und signature.certificate gesetzt ist; andernfalls bleibt der Abschnitt inaktiv.
• Stellen Sie Zertifikat, privaten Schlüssel und Passwort über Symfony-Secrets oder Umgebungsvariablen bereit; committen Sie sie niemals ins Repository.
• Beschränken Sie die Leserechte für das Schlüsselmaterial auf das Anwendungskonto.

Optionales Logging

Die Font- und Image-Registries akzeptieren ein optionales Psr\Log\LoggerInterface, das mit nullOnInvalid() gebunden ist. Wenn ein Logger vorhanden ist, fungiert er als austauschbarer Kollaborator gemäß dem PSR-3-Logger-Vertrag (PSR-3). Entfernen Sie benutzeridentifizierende Daten aus jedem Log-Kontext, den Sie rund um die Dokumenterzeugung hinzufügen; das Bundle loggt keine Dokumentinhalte.

Checkliste zur betrieblichen Härtung

• Behalten Sie die festen Response-Header bei; ergänzen Sie strengeres Caching für authentifizierte Downloads im Controller.
• Autorisieren Sie die Anfrage, bevor Sie ein Dokument erzeugen oder zurückgeben; das Bundle führt keine Zugriffskontrolle durch.
• Speichern Sie das Signatur-Schlüsselmaterial in Symfony-Secrets / Umgebungsvariablen mit minimalen Dateirechten.
• Führen Sie Messenger-Worker unter einem Konto mit minimalen Rechten aus, dessen Schreibzugriff auf das Ausgabeverzeichnis beschränkt ist.
• Halten Sie ext-mbstring und ext-zlib aktiviert (das Bundle bricht andernfalls früh ab).
• Pinnen Sie im Anwendungsprojekt einen einzelnen Major von nextpdf/core, um die Engine-Version über Deployments hinweg deterministisch zu halten.

Konformität

Jede Zeile auf dieser Seite ist eine normative Aussage, fixiert auf eine vollständige 64-stellige Hex-reference_id aus dem gegateten SDO-Korpus. Die Provenance (Korpus-Manifest, Retrieval-Transport) ist in _sidecars/rag-citations.yaml abgelegt.

Spezifikation	Klausel	reference_id	Aussage
PSR-11	psr_11_container#1.1.2.p5		has() false impliziert, dass get() eine NotFoundException wirft
PSR-3	psr_3_logger#x3.p17		Optionaler Logger-Kollaborator

Kommerzieller Kontext

Digitales Signieren ist nur verfügbar, wenn nextpdf/premium (Pro) installiert ist; das ausgelieferte Profil dieses Bundles ist das Baseline-Profil B-B. Diese Pro-Fähigkeit ist optional; das hier dokumentierte Core-Bundle benötigt keine Code-Änderung, um sie zu nutzen. Siehe </get-license/?intent=symfony-pro>.

Siehe auch

• /integrations/symfony/production-usage/ – Worker-Sicherheit und Streaming.
• /integrations/symfony/configuration/ – Tabellen für signature, tsa und Services.
• /integrations/symfony/troubleshooting/ – Diagnose von Signatur- und Messenger-Problemen.
• /integrations/symfony/integration/ – End-to-End-Referenz zur Verdrahtung.