Sicherheit

„Die ist veraltet" – Warum PHP, HTML, CSS und JavaScript nicht das Sicherheitsrisiko sind

~ 12 Minuten Lesezeit

Es gibt diesen Satz, den man in Besprechungen immer wieder hört.

„Die Webseite ist veraltet. Den Code versteht eh keiner mehr.”

Er fällt meistens beiläufig. Jemand zeigt eine Seite, die schon ein paar Jahre auf dem Buckel hat, das Design wirkt nicht mehr ganz taufrisch, und schon ist das Urteil gefällt: veraltet. Als wäre damit alles gesagt. Als wäre die Frage damit erledigt.

Ich habe mir in so einem Fall den betreffenden Code angeschaut. Genauer gesagt: den Stand im Webarchiv, weil die Seite inzwischen anders aussieht oder gar nicht mehr existiert. Und was fand ich dort? PHP. HTML. CSS. JavaScript.

Keine exotische Todeskandidaten-Technologie. Kein längst vergessenes Framework. Sondern exakt die vier Bausteine, aus denen das Web seit Jahrzehnten besteht – und aus denen es auch heute noch besteht.

Also: veraltet? Diese Frage lohnt eine genauere Betrachtung – vor allem, weil hinter „veraltet” in solchen Runden meist ein zweites, ernsteres Urteil mitschwingt: unsicher. Und genau darum geht es hier.

Was eine Webseite technisch eigentlich ist

Bevor man über „veraltet” urteilen kann, hilft es zu wissen, worüber man überhaupt redet. Eine Webseite ist im Kern erstaunlich simpel – und genau darin liegt ihre Stärke.

  • HTML beschreibt die Struktur: Was ist eine Überschrift, was ein Absatz, was ein Bild, was ein Link. Es ist die Sprache, in der Dokumente im Web formuliert werden.
  • CSS beschreibt das Aussehen: Farben, Abstände, Schriftarten, Layouts, Responsive Design für verschiedene Bildschirmgrößen.
  • JavaScript sorgt für Interaktivität im Browser: Formulare prüfen, Inhalte nachladen, Menüs aufklappen, Karten rendern.
  • PHP läuft auf dem Server und erzeugt das HTML, bevor es überhaupt zum Browser geschickt wird – etwa aus einer Datenbank, einem CMS oder einem Shop-System.

Das ist keine zufällige Auswahl aus einem Werkzeugkasten. HTML, CSS und JavaScript sind die drei Sprachen, die jeder Browser der Welt nativ versteht. Jeder. Es gibt keine Alternative dazu. Jeder noch so moderne JavaScript-Framework-Zauber wird am Ende zu genau diesen drei Technologien kompiliert, transpiliert oder ausgeliefert.

Und PHP? Läuft nicht im Browser, sondern auf dem Server – und produziert dort genau jenes HTML, das der Browser dann darstellt.

Alt ist nicht dasselbe wie veraltet

Hier beginnt das eigentliche Missverständnis.

„Alt” beschreibt, wann etwas entstanden ist. „Veraltet” beschreibt, ob es noch funktioniert, gepflegt wird und sinnvoll einsetzbar ist. Ein Hammer ist alt. Er ist nicht veraltet. Niemand behauptet, man könne heute keine Nägel mehr in Wände schlagen, nur weil das Werkzeug seit Jahrhunderten existiert.

Übertragen auf die Webseite aus der Besprechung: Ja, der Code war älter. Vielleicht zehn, fünfzehn, zwanzig Jahre. Aber er bestand aus Sprachen, die bis heute aktiv weiterentwickelt werden:

  • HTML wird von der WHATWG als „Living Standard” gepflegt. Es gibt kein „fertiges” HTML mehr – es wird kontinuierlich weiterentwickelt.
  • CSS bekommt laufend neue Module: Grid, Flexbox, Container Queries, :has(), Cascade Layers. Vieles davon ist jünger als manche der Frameworks, die als „modern” gelten.
  • JavaScript wird jährlich von der TC39 erweitert. Jede neue ECMAScript-Version bringt Sprachfeatures, die die Entwicklung verbessern.
  • PHP ist seit Version 8 eine moderne, schnelle Sprache mit Typsystem, JIT-Compiler und aktivem RFC-Prozess. Zwischen dem PHP von vor zwanzig Jahren und heute liegen Welten.

Wer also eine Seite aus diesen Technologien „veraltet” nennt, verwechselt das Alter des Codes mit dem Stand der Technologie. Das ist, als würde man sagen: „Das Auto ist von 2015, also sind Benzinmotoren überholt.”

Für die Sicherheit gilt derselbe Unterschied. Relevant ist nicht, wann eine Sprache erfunden wurde, sondern ob die verwendete Version noch gepflegt wird und Sicherheitsupdates bekommt. PHP 8.5 ist eine aktiv unterstützte Version. PHP 5.6 ist es nicht – es bekommt seit 2018 keine Sicherheitspatches mehr. Beides heißt „PHP”. Nur eines davon ist ein Risiko.

Die stillen Arbeitstiere des Webs

Es gibt einen weiteren Punkt, der in solchen Besprechungen gern übersehen wird: die schiere Verbreitung.

Ein erheblicher Teil des Internets läuft auf PHP. WordPress allein treibt nach diversen Erhebungen über 40 Prozent aller Webseiten an. MediaWiki – die Software hinter Wikipedia – ist PHP. Viele Shops, Vereinsseiten, Firmenauftritte und interne Anwendungen laufen seit Jahren stabil auf genau diesem Stack.

Und auf der Client-Seite ohnehin: Alles, was du im Browser siehst, ist HTML. Alles, was gut aussieht, ist CSS. Alles, was sich bewegt und reagiert, ist JavaScript. Auch wenn die Entwicklerin im Hintergrund TypeScript, React, Vue oder Svelte geschrieben hat – der Browser bekommt am Ende HTML, CSS und JavaScript zu sehen.

Auch Werkzeuge wie Hexo – ein leistungsfähiger, auf Node.js aufbauender Static Site Generator – zeigen das: Sie verwandeln Markdown-Inhalte, Themes und Plugins in schnelle, statische HTML-Seiten. Der Entwicklungsprozess fühlt sich dabei modern an, doch das fertige Ergebnis bleibt klassisch: reines HTML, das sich leicht überall hosten und deployen lässt. Auch wir nutzen Hexo selbst und sind von diesem Ansatz überzeugt: Er verbindet einen zeitgemäßen, komfortablen Workflow mit einem Ergebnis, das langlebig, offen und ohne unnötige Abhängigkeiten bleibt.

Man kann diese Technologien also gar nicht abschaffen, ohne das Web selbst abzuschaffen. Sie sind nicht „eine Technologie von vielen”. Sie sind die Plattform.

Die Angriffsfläche sitzt woanders

Und jetzt wird es interessant, wenn man das Sicherheitsargument ernst nimmt. Denn wo liegt das reale Einfallstor bei Webanwendungen?

Selten in der Sprache selbst. Die größten Risiken sind:

  • Ungepatchte Software: Eine alte WordPress-Installation mit veralteten Plugins ist ein Einfallstor – aber das Plugin und der Patchzustand sind das Problem, nicht PHP.
  • Injection-Fehler: SQL-Injection, XSS oder Command Injection entstehen durch fehlerhaften Code. Sie sind in jeder Sprache möglich – und in jeder vermeidbar.
  • Abhängigkeiten: Und hier dreht sich das Argument sogar um. Ein „modernes” JavaScript-Projekt zieht über npm install regelmäßig hunderte transitive Abhängigkeiten ins Projekt. Jede davon ist potenzieller fremder Code, dem man vertraut. Lieferkettenangriffe auf Paketregister – vom kompromittierten event-stream-Paket bis zu Typosquatting-Kampagnen – sind längst etablierte Angriffsvektoren.

Eine schlichte PHP-Seite mit einem Stylesheet und einer Handvoll eigenem JavaScript hat dagegen eine Angriffsfläche, die man an einem Nachmittag auditieren kann. Weniger Abhängigkeiten bedeuten weniger Code, dem man vertrauen muss, ohne ihn zu kennen. In der Sicherheit ist das kein Nachteil. Das ist ein Vorteil.

„Den Code versteht keiner mehr” – wessen Problem ist das?

Der zweite Satz aus der Besprechung verdient eine eigene Betrachtung: „Man versteht den Code nicht.”

Das kann durchaus stimmen. Aber es sagt etwas anderes aus, als die meisten denken.

Wenn ein Team heute komplett auf React, TypeScript, Server Components und Build-Pipelines geschult ist, dann sieht ein plaintes PHP-Projekt mit serverseitig gerendertem HTML fremd aus. Nicht weil es schlecht wäre, sondern weil es anders ist. Es gibt kein npm install, kein node_modules-Verzeichnis mit einer halben Million Dateien, keinen Transpiler. Es gibt eine .php-Datei, die HTML ausgibt. Punkt.

Das Unverständnis sagt also wenig über den Code – aber viel über den Abstand zwischen dem, was man gewohnt ist, und dem, was man betrachtet.

Natürlich gibt es echten Altcode, der wirklich schwer verständlich ist: Funktionen mit tausend Zeilen, Spaghettilogik, undokumentierte Abhängigkeiten, mysql_query statt Prepared Statements. Das ist ein Problem – aber ein Problem der Codequalität und Pflege, nicht der Sprache. Denselben unverständlichen Code kann man heute problemlos in jedem modernen Framework schreiben. Man muss es nur unordentlich genug treiben.

Fairerweise gilt das auch umgekehrt: Ein sauber strukturiertes PHP-Projekt von 2010 ist oft leichter zu verstehen als ein „modernes” Projekt mit zwölf Abstraktionsschichten, drei State-Management-Lösungen und einem Build-System, das niemand mehr durchschaut.

Sicherheitstechnisch ist das kein Nebenschauplatz. Code, den niemand im Team versteht, kann niemand auditieren. Schwachstellen werden nicht gefunden, Patches nicht eingespielt, Vorfälle nicht analysiert. Die Lösung dafür ist aber nicht zwingend „alles neu in einem anderen Stack” – sie ist Dokumentation, Einarbeitung und die Frage, ob die Anwendung überhaupt noch gewartet wird. Unbetreuter Code ist das Risiko, nicht die Sprache, in der er geschrieben ist.

Die Haltbarkeit als Feature

Es gibt noch eine andere Perspektive, die gerade jemandem wie mir naheliegt, der auch über digitale Souveränität schreibt: Die Langlebigkeit dieses Stacks ist kein Bug, sondern ein Feature.

Eine Webseite, die in sauberem HTML, CSS und etwas JavaScript geschrieben wurde, läuft in zwanzig Jahren noch. Sie braucht keine bestimmte Node-Version, keinen bundler, keine veraltete Abhängigkeit, deren Repository längst gelöscht ist. Sie braucht einen Browser. Mehr nicht.

Eine PHP-Anwendung läuft auf so gut wie jedem Webhosting-Angebot der Welt, vom billigsten Shared Hosting bis zum eigenen Server. Keine Container-Orchestrierung, kein Vendor Lock-in, kein Abo.

Und dann ist da noch das Webarchiv: Genau weil das Web auf diesen offenen Standards aufbaut, kann man eine Seite aus dem Jahr 2005 heute in der Wayback Machine aufrufen – und sie rendert. Das ist ein bemerkenswertes Versprechen, das kaum eine andere Technologie so halten kann. Die Dateiformate, in denen deine Dokumente vor zwanzig Jahren gespeichert wurden, kannst du zum Teil nicht mehr öffnen. Eine HTML-Seite von 2005? Ein Doppelklick, fertig.

Wer eine solche Seite „veraltet” nennt, übersieht, dass sie vielleicht das Langlebigste ist, was die Firma an Software besitzt.

Aus Sicherheitssicht bedeutet Haltbarkeit außerdem: Der Code ist stabil, bekannt und erprobt. Bekannte Schwachstellen sind längst gefunden und behoben. Ein kompletter Neubau bedeutet dagegen neue Bugs, neue Abhängigkeiten, neue Angriffsfläche – und garantiert keinen einzigen Sicherheitsgewinn, wenn das Team die neuen Technologien nicht beherrscht.

Woher kommt dann der Ruf?

Der Impuls, „altes” Web abzulehnen, hat reale Gründe. Man sollte sie ernst nehmen:

  • Design altert schnell. Eine Seite, die 2012 modern aussah, wirkt heute angestaubt. Das ist aber ein Designproblem, kein Technologieproblem. CSS kann man ändern, ohne die Sprache zu wechseln.
  • Framework-Hype und Lebenslauf-Entwicklung. In der Branche lohnt es sich individuell oft, mit dem Neuesten zu arbeiten. „Wir bauen neu in React” klingt im Portfolio besser als „Wir pflegen eine gut funktionierende PHP-Anwendung”. Das ist eine Karriereentscheidung – keine technische Notwendigkeit.
  • Unkenntnis. Wer nie gelernt hat, wie ein Server HTTP-Anfragen beantwortet und HTML ausliefert, für den wirkt ein PHP-Template wie Magie. Dabei ist es die Grundlagen dessen, wie das Web funktioniert.
  • Marketing. Die Industrie verdient an Neuem. Cloud-Plattformen, Frameworks, Toolchains – alle haben ein Interesse daran, „das Alte” als überholt zu framen.

Das heißt nicht, dass Frameworks sinnlos sind. Für komplexe Anwendungen mit viel Client-State können sie absolut sinnvoll sein. Aber „es gibt etwas Neueres” ist kein Argument dafür, dass das Bestehende veraltet ist.

Wann eine Webseite sicherheitstechnisch wirklich veraltet ist

Es gibt legitime Kriterien – und die sind messbar. Eine Webanwendung ist aus Sicherheitssicht veraltet, wenn:

  • sie auf einer End-of-Life-Version läuft, die keine Sicherheitspatches mehr bekommt (z. B. PHP 5.x/7.x, ein EOL-Node-Release, ein nicht mehr unterstütztes CMS),
  • bekannte CVEs in eingesetzten Komponenten ungepatcht bleiben,
  • kein HTTPS bzw. veraltete TLS-Versionen genutzt werden,
  • Injection-Schwachstellen wie SQL-Injection oder XSS im Code stecken (etwa mysql_query mit zusammengebastelten Strings statt Prepared Statements),
  • Security-Header und grundlegende Härtung fehlen,
  • niemand mehr weiß, wie deployed und gepatcht wird,
  • oder keine Backups und kein Monitoring existieren, um einen Vorfall überhaupt zu bemerken.

Zum praktischen Nachschlagen: Auf endoflife.date steht für PHP, Node.js, WordPress & Co., welche Version noch Sicherheitsupdates bekommt und welche nicht. Ein Blick dorthin beantwortet die Frage „veraltet?” in zwei Minuten – belastbarer als jedes Bauchgefühl in der Besprechung.

Beachte: Die verwendete Sprache taucht in dieser Liste nicht auf. „PHP” ist kein CVE. „HTML” ist kein Verfallsdatum. „Veraltet” ist im Sicherheitskontext eine Eigenschaft des Patchzustands, nicht der Technologie.

Eine PHP-Anwendung auf einer aktuellen PHP-8-Version, mit HTTPS, Prepared Statements, Security-Headern und regelmäßigen Updates ist sauber betrieben – auch wenn der erste Commit vor fünfzehn Jahren war. Eine Single-Page-App mit einer drei Jahre alten Node-Toolchain, 800 veralteten Abhängigkeiten und unbekannten kritischen CVEs ist es nicht – auch wenn sie erst von letztem Jahr ist.

Ein Fall fürs Archiv

Zurück zu meiner kleinen Recherche. Die Seite im Webarchiv bestand aus PHP, das serverseitig HTML erzeugte. Ein Stylesheet. Ein bisschen JavaScript für Formulare und Navigation. Kein Build. Kein Framework. Keine Abhängigkeit zu einem Dienst, der heute nicht mehr existiert.

„Veraltet” hieß in der Besprechung im Kern: „Es sieht nicht mehr aus wie das, was wir gerade für modern halten – und wir kennen uns mit der Technik nicht mehr aus.”

Das sind reale Probleme. Aber sie sind lösbar. Ein Redesign ist Arbeit am CSS und am Markup. Fehlendes Wissen ist eine Dokumentations- oder Einarbeitungsfrage. Und falls die Runtime tatsächlich end-of-life ist, ist ein Versionsupgrade ein definierter, begrenzter Aufwand. Keines davon rechtfertigt das Urteil „veraltet” – und schon gar nicht die Folgeentscheidung, alles wegzuwerfen und von vorn anzufangen, nur weil der Name der Sprache nicht mehr im Trend ist. Ein Neubau unter Zeitdruck, in Technologien, die das Team nicht beherrscht, ist aus Sicherheitssicht die riskantere Option.

Fazit

Die Technik hinter dem Web ist älter als viele der Entwickler, die sie heute verwenden – und sie wird aktiv weiterentwickelt. HTML, CSS und JavaScript sind keine Legacy-Entscheidungen, sondern die aktuellen Standards des offenen Webs. PHP ist kein Relikt, sondern eine moderne, performante Sprache, die nach wie vor große Teile des Internets trägt.

Sicherheit entsteht nicht dadurch, dass man eine Sprache wechselt. Sie entsteht durch gepatchte Versionen, geprüfte Abhängigkeiten, verständlichen Code und Menschen, die wissen, was sie betreiben. Eine schlichte, gut gepflegte PHP-Seite kann sicherer sein als ein hipper Stack mit tausend unauditierten Abhängigkeiten.

Wer das nächste Mal in einer Besprechung hört, eine Webseite sei „veraltet, weil PHP und HTML”, der darf eine einfache Frage stellen:

Veraltet woran genau?

Wenn die Antwort „End-of-Life-Version, ungepatchte CVEs, kein HTTPS” lautet – dann lohnt das Gespräch. Wenn die Antwort nur das Alter oder die Sprache betrifft, dann steht da kein Security-Audit, sondern ein Modewort.

Das Web hat einen bemerkenswerten Vorteil: Seine Grundlagen altern nicht, sie reifen. Die Seite aus dem Archiv ist der Beweis dafür – sie rendert heute noch. Ob sie sicher betrieben wird, hängt nicht an den Sprachen, aus denen sie gebaut ist. Sondern daran, ob jemand sie pflegt.

Quellen

Ähnliche Artikel