Datei-Uploads kontrolliert verarbeiten

Ein Upload ist eine Annahmeentscheidung

Ein Dateiupload übernimmt fremde Bytes in den eigenen Verantwortungsbereich. Deshalb braucht er einen ausdrücklich beschriebenen Zweck. Welche Dateien werden benötigt, wer darf sie einstellen und was geschieht anschließend damit? Die Dateiauswahl im Browser beantwortet diese Fragen nicht. Ein hübscher Ablagebereich kann die Bedienung erleichtern, ersetzt aber weder die serverseitige Annahmeregel noch die spätere Berechtigung zum Abruf.

Unser vollständiges Beispiel behandelt ausschließlich statische Bildvorlagen als JPEG oder PNG. Ein eigener PHP-Baustein prüft den tatsächlichen Upload, Dateigröße, erkannten Typ, Abmessungen und die Dekodierbarkeit. Danach wird ein neues WebP-Bild unter einer zufälligen Kennung in einer privaten Ablage erzeugt. Es werden eigene künstliche Bilddateien verwendet und keine echten Kundendokumente verarbeitet.

Der Baustein wurde über echte lokale HTTP-Uploads geprüft. Die 74 Bedingungen betreffen 17 ausdrücklich geprüfte HTTP-Anfragen und zusätzliche Kontrollen der gespeicherten Ergebnisse. Der Versuch ist kein vollständiges öffentliches Uploadangebot mit Anmeldung und Freigabeverwaltung. Er zeigt einen begrenzten Annahmekern, dessen Verhalten anhand konkreter zulässiger und unzulässiger Dateien nachvollziehbar bleibt.

Den Dateivertrag aus der Aufgabe ableiten

Legen Sie nicht zuerst eine möglichst lange Liste erlaubter Endungen an. Klären Sie zunächst, welche Inhalte der folgende Arbeitsschritt tatsächlich braucht. Ein Bild für eine Profilansicht hat andere Anforderungen als ein unterschriebener Vertrag oder ein Datenaustauscharchiv. Unser Beispiel benötigt ein dekodierbares Rasterbild. SVG, PDF und GIF gehören deshalb nicht zu seinem Vertrag, unabhängig davon, ob sie in anderen Anwendungen sinnvoll wären.

Die feste Grenze beträgt zwei MiB je Datei, höchstens 4000 Pixel in jeder Richtung und insgesamt höchstens acht Millionen Pixel. Diese Zahlen sind gewählte Grenzen des Beispiels und keine universelle Größenempfehlung. Die Kombination ist wichtig, weil eine kleine komprimierte Datei trotzdem ein sehr großes dekodiertes Bild beschreiben kann. Allein die Anzahl übertragener Bytes erklärt nicht den späteren Verarbeitungsaufwand.

Die Ausgabe ist ein neu erzeugtes statisches WebP. Sie ist keine unveränderte Archivkopie des Originals. Wer rechtlich oder fachlich das ursprüngliche Dokument erhalten muss, braucht einen anderen ausdrücklich entwickelten Ablauf. Ebenso gehören Orientierung, Farbprofil und gegebenenfalls weitere Bildanforderungen in die tatsächliche Produktentscheidung. Unser kleiner Entwurf behauptet keine vollständige fotografische Aufbereitung aller möglichen JPEG- und PNG-Varianten.

Browserauswahl und Serverentscheidung auseinanderhalten

Ein Auswahlfeld kann mit accept passende Formate vorschlagen. Diese Angabe ist eine Bedienhilfe und kein Sicherheitsnachweis. Andere Programme können eine Anfrage ohne dieses Feld senden. Auch ein vom Client angegebener MIME-Typ kann frei gewählt sein. Deshalb verwendet unser Annahmekern nicht die Behauptung des Absenders als verbindliche Typentscheidung, sondern untersucht die tatsächlich eingegangene Datei.

Der Originalname wird nicht als Speicherpfad verwendet. Im Versuch wird ein gültiges PNG sogar mit einem pfadähnlichen PHP-Dateinamen und einem falschen Client-Typ übermittelt. Es bleibt anhand seines Inhalts ein gültiges Bild und erhält eine neue WebP-Kennung. Der gezeigte Vertrag entscheidet bewusst nach Inhalt. Eine reale Oberfläche kann zusätzlich Namenskonventionen verlangen, darf diese aber nicht mit der Inhaltsprüfung verwechseln.

Diese Entscheidung bedeutet nicht, beliebige Inhalte unter einer neuen Endung abzuspeichern. Ein als JPEG bezeichnetes HTML-Dokument wird zurückgewiesen. Ein SVG mit PNG-Namen ebenfalls. Erst die Kombination aus erkannter erlaubter Bildart, Größenregeln und erfolgreicher Dekodierung ermöglicht die neue Bildausgabe. Der Absender kontrolliert damit weder den endgültigen Pfad noch ein ungeprüft in den öffentlichen Bereich kopiertes Original.

Die tatsächlichen Uploadzustände prüfen

PHP stellt für einen Upload einen Fehlerzustand bereit. Unser Code verlangt zunächst eine einzelne passende Struktur mit einem ganzzahligen Fehlerwert. Eine nicht erfolgreich übernommene Datei wird nicht weiterverarbeitet. Ein vom Laufzeitlimit abgewiesener Upload unterscheidet sich dabei von einer ungültigen Dateiart oder einem später nicht dekodierbaren Bild. Diese Zustände sollten auch in einer realen Rückmeldung verständlich auseinandergehalten werden.

Zusätzlich prüft is_uploaded_file, dass der verwendete temporäre Pfad tatsächlich zu einem HTTP-Upload dieses PHP-Ablaufs gehört. Ein gewöhnlicher lokaler Dateipfad wird im Gegenversuch zurückgewiesen. Die Funktion verhindert damit die hier betrachtete Verwechslung von einem fremden Formularupload und einer beliebig benannten vorhandenen Datei. Sie ersetzt keine Anmeldung, keine Formularfreigabe und keine Berechtigung für das eigentliche Zielobjekt.

Eine leere Datei wird anhand ihrer tatsächlichen Größe erkannt. Die übertragene Größe aus einer frei gestalteten Oberfläche dient nicht als Beweis. Für die maximale Dateigröße werden ebenfalls die vorhandenen Bytes betrachtet. Eine private Testannahme ohne Datei und eine Mehrfachstruktur statt des vereinbarten Einzelbilds werden zurückgewiesen. So bleibt der Eingabevertrag auch außerhalb des idealen Standardformulars eindeutig.

PHP: is_uploaded_file · Uploadfehler

Typ, Bildkopf und Dekodierung als mehrere Prüfungen nutzen

Die Dateiinfo ermittelt den erkannten Typ. Nur PNG und JPEG werden anschließend weiter betrachtet. Danach liest der Baustein die Bildabmessungen und prüft Richtungslimits sowie Pixelanzahl. Erst im nächsten Schritt wird das vollständige Bild mit GD dekodiert. Ein vorhandener Bildkopf allein genügt nicht. Der beschädigte PNG-Gegenversuch besitzt noch Teile eines Bildkopfs, scheitert aber an der tatsächlichen Dekodierung.

Keine dieser einzelnen Prüfungen wird als universelle Schadsoftwareerkennung bezeichnet. Die verwendeten Bibliotheken brauchen einen gepflegten Laufzeitstand und passende Ressourcenbegrenzungen. Ein Bildparser ist zusätzliche Verarbeitung fremder Daten. Für besonders exponierte oder große Abläufe kann eine stärker isolierte Verarbeitung erforderlich sein. Unser Versuch belegt die konkreten Annahmefälle, nicht die Fehlerfreiheit jeder verwendeten Bibliothek gegenüber unbekannten Dateien.

Die Pixelbegrenzung wird vor der vollständigen Dekodierung angewendet. Ein 4001 Pixel breites Bild und ein Bild mit neun Millionen Pixeln werden so bereits an dieser Stelle abgewiesen. Die tatsächlich ausgeführten Prüfungen verwenden eigene entsprechende Dateien. Daraus folgt keine allgemeine Antwortzeit- oder Speicherverbrauchsmessung. Die Grenzwerte sind Teil des ausdrücklich gewählten Vertrags und müssen für eine reale Umgebung passend geprüft werden.

PHP: Dateiinfo · Bilddekodierung

Die private Ausgabe neu erzeugen

Aus einem erfolgreich dekodierten Bild erzeugt der Code eine neue WebP-Datei. Der ursprüngliche Name und die ursprüngliche Erweiterung werden dafür nicht übernommen. Eine zufällige Kennung bestimmt den Dateinamen. Die Datei wird exklusiv neu angelegt. Ein weiterer Upload mit demselben ursprünglichen Namen erzeugt einen anderen Eintrag und überschreibt nicht die vorherige Datei. Das wird im tatsächlichen Versuch kontrolliert.

Die private Zielablage wird von der Anwendung vorgegeben und muss außerhalb des öffentlich ausgelieferten Bereichs liegen. Der Baustein erhält diesen vertrauenswürdigen Verweis von seinem Aufrufer. Er nimmt ihn nicht aus einem Formularfeld entgegen. Die lokale Testanordnung trennt öffentliche Annahmedatei und private Ergebnisdateien tatsächlich. Ein direkter HTTP-Aufruf auf einen vermeintlichen Ergebnisweg liefert dort 404.

Der Rückgabewert enthält nur Kennung, Ausgabeformat, Abmessungen und Bytezahl. Er erteilt keine Abrufberechtigung und veröffentlicht keine Datei. Eine reale Anwendung kann diese Kennung einem berechtigten Vorgang zuordnen. Die spätere Speicherung dieser Beziehung und der geschützte Abruf sind zusätzliche Aufgaben. Ein zufälliger Dateiname allein ist keine vollständige Zugriffskontrolle und darf nicht als solche bezeichnet werden.

Den vollständigen Annahmekern lesen

Der folgende PHP-Code enthält die vollständige begrenzte Bildannahme. Er verwendet Dateiinfo und GD sowie die von PHP bereitgestellte Uploadzuordnung. Bei einem Fehler liefert er einen klaren internen Ablehnungsgrund oder beendet die Ausgabe mit einer Ausnahme. Der öffentliche Integrationsweg muss solche Zustände in angemessene verständliche Rückmeldungen übersetzen, ohne dabei interne Pfade oder vertrauliche Diagnosen auszugeben.

Die Schreibbereinigung betrifft ausschließlich die gerade von dieser Funktion neu angelegte Ergebnisdatei. Der Baustein löscht keine anderen vorhandenen Bilder und räumt keinen allgemeinen Ordner auf. Bei erfolgreichem Abschluss bleibt das neue Ergebnis für die anschließende Zuordnung erhalten. Wie lange nicht zugeordnete Dateien aufbewahrt werden und wer sie entfernen darf, gehört in den Lebenszyklus der tatsächlichen Anwendung.

<?php
declare(strict_types=1);
final class UploadRejected extends RuntimeException {
 public function __construct(public readonly int $status, public readonly string $reason) {
  parent::__construct($reason);
 }
}
function storeImageUpload(array $file, string $privateDirectory): array {
 if (!isset($file['error']) || !is_int($file['error'])) throw new UploadRejected(400,'invalid_upload');
 if ($file['error'] !== UPLOAD_ERR_OK) {
  $tooLarge=in_array($file['error'],[UPLOAD_ERR_INI_SIZE,UPLOAD_ERR_FORM_SIZE],true);
  throw new UploadRejected($tooLarge?413:400,'upload_error');
 }
 $tmp=$file['tmp_name']??null;
 if (!is_string($tmp)||!is_uploaded_file($tmp)) throw new UploadRejected(400,'not_uploaded');
 $bytes=filesize($tmp);
 if ($bytes===false||$bytes<1) throw new UploadRejected(400,'empty_file');
 if ($bytes>2*1024*1024) throw new UploadRejected(413,'file_too_large');
 $mime=(new finfo(FILEINFO_MIME_TYPE))->file($tmp);
 if (!in_array($mime,['image/png','image/jpeg'],true)) throw new UploadRejected(415,'type_not_allowed');
 $size=@getimagesize($tmp);
 if ($size===false||$size[0]<1||$size[1]<1) throw new UploadRejected(422,'invalid_image');
 [$width,$height]=$size;
 if ($width>4000||$height>4000||$width>intdiv(8_000_000,$height)) throw new UploadRejected(413,'image_dimensions');
 $raw=file_get_contents($tmp);
 $image=$raw===false?false:@imagecreatefromstring($raw);
 if ($image===false) throw new UploadRejected(422,'decode_failed');
 $directory=realpath($privateDirectory);
 if ($directory===false||!is_dir($directory)||!is_writable($directory)) {
  imagedestroy($image);throw new RuntimeException('Private Ablage nicht verfügbar.');
 }
 $id=bin2hex(random_bytes(16));
 $path=$directory.DIRECTORY_SEPARATOR.$id.'.webp';
 $handle=@fopen($path,'xb');
 if ($handle===false) {imagedestroy($image);throw new RuntimeException('Ablage konnte nicht angelegt werden.');}
 try {
  imagealphablending($image,false);imagesavealpha($image,true);
  if (!imagewebp($image,$handle,88)||!fflush($handle)) throw new RuntimeException('Bildausgabe fehlgeschlagen.');
 } catch (Throwable $error) {
  fclose($handle);imagedestroy($image);unlink($path);throw $error;
 }
 fclose($handle);imagedestroy($image);
 $storedBytes=filesize($path);
 if ($storedBytes===false||$storedBytes<1) {unlink($path);throw new RuntimeException('Leere Bildausgabe.');}
 // Only metadata is returned. This does not grant a public download URL.
 return ['id'=>$id,'mime'=>'image/webp','width'=>$width,'height'=>$height,'bytes'=>$storedBytes];
}

Neu erzeugte Bilddaten sind keine unveränderten Originale

Ein Gegenversuch hängt an ein gültiges PNG einen ausdrücklich benannten zusätzlichen Marker an. Das Bild bleibt im Versuch dekodierbar und wird neu erzeugt. Der Marker ist in der gespeicherten WebP-Ausgabe nicht mehr enthalten. Das zeigt konkret, dass nicht einfach die ursprüngliche Datei unter neuem Namen verschoben wird. Die Prüfung liest die tatsächlichen gespeicherten Bytes und kontrolliert ihren erkannten Ausgabetyp.

Dieser einzelne Befund ist keine allgemeine Garantie, dass jede denkbare gefährliche Eigenschaft aus jedem möglichen Bild entfernt wäre. Auch eine unpassende Bildaussage, unzulässige Inhalte oder fremde Rechte verschwinden nicht durch ein neues Dateiformat. Der technische Annahmekern prüft keine Nutzungsrechte und keine redaktionelle Eignung. Solche fachlichen Entscheidungen bleiben Bestandteil der tatsächlichen Freigabe und können andere Prüfungen erfordern.

Die WebP-Erzeugung verwendet im Beispiel eine feste Qualitätsstufe. Sie behauptet keine verlustfreie Archivierung. Metadaten, Ausrichtung und Farbverhalten sind für ein echtes Bildprodukt ausdrücklich zu betrachten. Wer das Original benötigt, muss dessen gesonderte geschützte Aufbewahrung bewusst entwickeln. Ein Uploadkonzept sollte nicht gleichzeitig Originaltreue und beliebige Umformung versprechen, ohne die Bedeutung beider Ziele zu klären.

Laufzeitgrenzen und Anwendungsgrenzen gemeinsam planen

Eine Anfrage kann bereits vom Webserver oder von PHP zurückgewiesen werden, bevor der eigentliche Bildbaustein arbeitet. Deshalb müssen maximale Anfragegröße, PHP-Uploadgrenze, temporäre Ablage und die eigene Dateigrenze zusammenpassen. Der lokale Versuch verwendet ausdrücklich eine PHP-Uploadgrenze oberhalb der eigenen Zwei-MiB-Regel. So lässt sich der Anwendungsfall mit einer zu großen, tatsächlich übernommenen Datei gezielt prüfen.

Eine Anfrage mit mehreren Dateien oder umfangreichen zusätzlichen Feldern kann eine andere Gesamtgröße besitzen als das einzelne Bild. Die eigene Feldprüfung ersetzt keine Gesamtanfragegrenze. Ebenso sind Zeitgrenzen, Speicherbudget und Parallelität für eine reale Veröffentlichung zu planen. Die 17 geprüften HTTP-Anfragen dieses Beitrags sind Funktionsfälle und keine Belastungssimulation mit vielen gleichzeitigen Empfängern.

Für große Verarbeitungsschritte kann eine Warteschlange mit getrenntem Arbeitsprozess sinnvoll sein. Dann sind Annahme, Prüfung, Verarbeitung und Freigabe unterschiedliche Zustände. Eine frühe Eingangsbestätigung darf kein fertig verarbeitetes Bild vortäuschen. Unser Beispiel arbeitet synchron mit kleinen festen Grenzen. Es liefert erst nach der neuen Bildausgabe seine Metadaten und behauptet keine bereits vorhandene Hintergrundverarbeitung.

Anmeldung, Formularschutz und fachliche Berechtigung ergänzen

Der ausgeführte lokale Testempfänger ist ausschließlich eine isolierte Versuchsanordnung. Er ist kein öffentlich bereitzustellender Ersatz für die Anmeldung einer Anwendung. Eine produktive Integration muss vor der Annahme klären, wer die Datei für welches Objekt einstellen darf. Auch die späteren Verknüpfungen brauchen dieselbe passende Zuordnung. Der Dateiname oder ein MIME-Typ trägt keine solche Berechtigung.

Bei sitzungsbasierten Formularen gehören die passenden Schutzregeln gegen fremd ausgelöste Aktionen dazu. Zusätzlich können Häufigkeitsgrenzen, ein Speicherbudget und eine eigene Freigabe erforderlich sein. Diese Aufgaben sollten nicht mit der erfolgreichen Bilddekodierung vermischt werden. Ein erlaubtes Bild kann von einer unberechtigten Person hochgeladen werden. Umgekehrt kann eine berechtigte Person versehentlich eine unzulässige Datei auswählen.

Die begrenzte Funktion bleibt dadurch nützlich, ohne mehr zu versprechen als sie leistet. Ihr Aufrufer liefert bereits geklärten Anwendungskontext und eine vertrauenswürdige private Ablage. Sie prüft anschließend den konkreten Einzelbildvertrag. Die vollständige Anwendung verbindet diese Ebenen und nimmt ihre realen Abläufe ab. Eine bloß erfolgreiche Funktionseinheit ist keine automatische Sicherheitsfreigabe des gesamten Veröffentlichungswegs.

74 ausgeführte Bedingungen an echten HTTP-Uploads

Die Prüfung verwendet PHP 8.4.27 mit Dateiinfo und GD. Gültiges PNG, gültiges JPEG, ein wiederholter Originalname und ein bewusst irreführender Clientname werden tatsächlich per HTTP übertragen. Die Ergebnisse erhalten unterschiedliche zufällige Kennungen und neue WebP-Dateien. Die gespeicherten Ausgaben werden zusätzlich erneut auf Typ und Abmessungen untersucht. Die fiktiven Bilder besitzen jeweils 80 mal 50 Pixel.

Die abgelehnten Fälle umfassen als JPEG bezeichnetes HTML, als PNG bezeichnetes SVG, GIF, ein zu großes Dateivolumen, überschrittene Breite, überschrittene Pixelanzahl und ein beschädigtes PNG. Hinzu kommen leere Datei, fehlende Datei und die nicht vereinbarte Mehrfachstruktur. Diese abgewiesenen Fälle erzeugen keine zusätzlichen Ergebnisdateien. Ein direkter Zugriff auf den privaten Ergebnisbereich bleibt erfolglos.

Der Marker-Gegenversuch und die Ablehnung einer gewöhnlichen lokalen Datei statt eines echten Uploads ergänzen den Nachweis. Die Erklärgrafik verwendet tatsächliche Rückgaben und gespeicherte Beispielbilder. Es wird weder ein Antivirenprodukt bewertet noch eine repräsentative Angriffs- oder Lastquote gemessen. Die 74 Bedingungen belegen den hier gezeigten Annahmekern und die konkrete Trennung der lokalen Testablage.

Rückmeldungen auf die nächste Handlung ausrichten

Eine Person sollte nach einer Ablehnung wissen, was sie ändern kann. Bildart nicht erlaubt, Datei zu groß und beschädigtes Bild sind unterschiedliche Hinweise. Die Oberfläche kann daraus passende Meldungen bilden und die bereits gültigen anderen Angaben erhalten. Interne Kennungen wie decode_failed sind für den technischen Nachweis nützlich, müssen aber nicht als unverständliche Produkttexte an die Nutzer weitergereicht werden.

Die Oberfläche sollte auch den gewählten Vertrag vor der Auswahl erklären. Für dieses Beispiel wären JPEG oder PNG, die Bytegrenze und die maximale Bildgröße relevant. Die endgültige Serverprüfung bleibt trotzdem notwendig. Eine vorherige Prüfung im Browser kann einen unnötigen Übertragungsversuch vermeiden und die Bedienung verbessern, muss aber dieselben Regeln verständlich wiedergeben statt einen eigenen widersprüchlichen Satz von Grenzen einzuführen.

Bei mehreren Verarbeitungsschritten zeigt die Rückmeldung den tatsächlich erreichten Zustand. Eine angenommene Datei kann noch geprüft oder einem Vorgang zugeordnet werden müssen. Ein roter oder grüner Rahmen allein erklärt diese Unterschiede nicht zuverlässig. Die konkrete Anwendung braucht verständliche Namen und einen erreichbaren Korrekturweg. Die technischen Statuswerte des kleinen Bausteins liefern dafür eine Grundlage, nicht die vollständige Besucheroberfläche.

Abruf, Austausch und Löschung als eigenen Lebenszyklus behandeln

Ein gespeichertes Bild bleibt Teil eines Vorgangs. Wer es später sehen oder austauschen darf, wird erneut durch die Anwendung entschieden. Ein zufälliger Bezeichner erschwert bloßes Raten, ersetzt aber keine Berechtigungsprüfung. Für private Dateien ist deshalb ein ausdrücklich entwickelter Abrufweg sinnvoll. Der vorliegende Versuch veröffentlicht seine Ergebnisse nicht und implementiert keinen Downloadendpunkt.

Bei einem Austausch darf die vorherige Datei nicht vor erfolgreicher Zuordnung des neuen Ergebnisses unkontrolliert verschwinden. Umgekehrt sollten dauerhaft nicht mehr benötigte Dateien nicht ohne geregelten Zweck liegen bleiben. Ein produktiver Ablauf muss Datei und zugehörigen Datensatz gemeinsam betrachten. Fehler zwischen Dateiausgabe und Datenbankzuordnung erfordern eine nachvollziehbare Behandlung, die unser isolierter Annahmekern noch nicht stellvertretend implementiert.

Ein Löschauftrag betrifft den konkreten zugeordneten Inhalt und seine tatsächlichen Aufbewahrungsregeln. Er ist kein Anlass für eine pauschale Ordnerbereinigung anhand vom Client gelieferter Pfade. Die neue Kennung und die private Ablage helfen, diese Zuständigkeiten sauber zu beschreiben. Erst der vollständige überprüfte Lebenszyklus macht aus einer funktionierenden Bildannahme eine verlässliche Uploadfunktion im eigenen Produkt.

Den Übergang zur Veröffentlichung bewusst offenhalten

Eine erfolgreiche Bildannahme ist zunächst ein technisch erzeugtes Ergebnis. Sie bedeutet noch nicht, dass die Abbildung öffentlich gezeigt werden soll. Redaktionelle Auswahl, Rechte am Bild und die richtige Zuordnung können weitere Entscheidungen verlangen. Gerade bei einem privaten Kundenvorgang muss die Anwendung diese Grenze erhalten. Der gespeicherte Dateiname ist deshalb kein automatisch erzeugter öffentlicher Link und die Rückgabe enthält auch keine solche Zusage.

Für die konkrete Umsetzung wird festgelegt, welche Rolle das Ergebnis freigeben darf und wie eine spätere Rücknahme wirkt. Falls verschiedene Bildgrößen entstehen, gehören sie gemeinsam zum selben Inhalt. Ein Austausch muss dann alle tatsächlich verwendeten Varianten berücksichtigen. Auch eine Sicherung kann einen früheren Stand enthalten. Diese Fragen werden anhand des realen Veröffentlichungswegs entschieden und nicht durch das bloße Vorhandensein einer Datei im Ordner beantwortet.

Tatsächlich geprüfte Annahmefälle

Checkliste für kontrollierte Uploads

• Zweck, zulässige Inhalte und Folgeaktionen vorab festlegen.
• Anmeldung und Berechtigung vor der eigentlichen Annahme prüfen.
• Clientnamen und Client-Typ nicht als verbindliche Inhaltsprüfung verwenden.
• Uploadfehler und echten temporären Uploadpfad kontrollieren.
• Bytes, Abmessungen und Pixelmenge sinnvoll begrenzen.
• Erkannten Typ und tatsächliche Dekodierung gemeinsam prüfen.
• Neue Ausgabe unter einer eigenen Kennung privat speichern.
• Gespeicherte Ergebnisse anhand echter Bytes nachprüfen.
• Veröffentlichung, Abruf, Austausch und Löschung gesondert berechtigen.
• Grenzen, Bibliotheken und reale Einbindung vor Veröffentlichung abnehmen.

Quellen und Prüfstand

Primärquellen am 09.11.2026 geprüft. Eigene künstliche Bilddateien, 74 ausgeführte Bedingungen und 17 ausdrücklich geprüfte HTTP-Anfragen mit PHP 8.4.27. Der isolierte Testempfänger ist kein öffentlicher Anmelde- oder Downloadablauf. Keine allgemeine Schadsoftware- oder Lastgarantie.

• OWASP: File Upload
• PHP: File Uploads
• PHP: is_uploaded_file
• PHP: finfo_file
• PHP: imagecreatefromstring
• PHP: imagewebp
• PHP: Upload Error Codes