Server & X-Powered-By im HTTP: Risiken durch Informations-Leaks
Die HTTP-Antwort-Header Server und X-Powered-By gehören standardmässig zu den gesprächigsten Headern im Web. Sie verraten dem anfragenden Client Details über die Server-Software und das dahinterstehende Web-Framework. Was für Entwickler im Debugging-Alltag praktisch klingt, ist im Live-Betrieb ein erhebliches Sicherheitsrisiko (Information Disclosure). Eine der wichtigsten Härtungsmassnahmen für Webserver besteht darin, diese Header zu deaktivieren oder auf ein Minimum zu reduzieren.
Das Anonymisieren dieser Header gehört zu jeder seriösen Security-Header-Checkliste und ergänzt die eigentlichen Schutz-Header. Wer die HTTP-Header-Grundlagen kennt, erkennt schnell, welche Header rein funktional sind und welche unnötig Informationen preisgeben.
Das Risiko: Automatisierte Spionage (Reconnaissance)
Bevor Cyberkriminelle einen Server angreifen, führen sie eine Informationsbeschaffung (Reconnaissance) durch. Sie nutzen Bots (oder Suchmaschinen wie Shodan), um Millionen IP-Adressen im Web abzutasten.
Trägt ein Server standardmässig folgende Header aus:
Server: nginx/1.18.0 (Ubuntu)
X-Powered-By: PHP/7.4.3
erhält der Angreifer wertvolle Informationen auf dem Silbertablett:
- Software & Version: Er weiss, dass Nginx 1.18.0 und PHP 7.4.3 verwendet werden.
- Betriebssystem: Die Nennung von Ubuntu verrät die Linux-Distribution.
- Gezielter Angriff: Der Angreifer gleicht diese Versionen sofort mit öffentlichen Schwachstellen-Datenbanken (CVE) ab. Findet er eine ungepatchte Sicherheitslücke für PHP 7.4.3, kann er einen gezielten Exploit-Angriff starten. Wären die Header anonymisiert, müsste er blind testen, was die Entdeckungswahrscheinlichkeit durch Firewalls (WAF) drastisch erhöht.
Informations-Header und ihr Risiko
Die folgende Übersicht zeigt, welche Header typischerweise zu viel preisgeben:
| Header | Beispielwert | Verrät | Empfehlung |
|---|---|---|---|
Server | nginx/1.18.0 (Ubuntu) | Software, Version, OS | auf nginx reduzieren/entfernen |
X-Powered-By | PHP/7.4.3 | Sprache, Version | entfernen |
X-AspNet-Version | 4.0.30319 | .NET-Version | entfernen |
X-Generator | Drupal 9 | CMS und Version | entfernen |
Vorher/Nachher: eine gehärtete Antwort
Vorher (gesprächig):
HTTP/2 200
Server: nginx/1.18.0 (Ubuntu)
X-Powered-By: PHP/7.4.3
Nachher (gehärtet):
HTTP/2 200
Server: nginx
Der gehärtete Server nennt weder Versionsnummer noch Betriebssystem noch das Backend-Framework – automatisierte Scanner finden keinen direkten Ansatzpunkt mehr.
Konfigurations-Leitfaden zur Deaktivierung
Webmaster sollten die Header so konfigurieren, dass sie keine Versionsnummern mehr verraten oder komplett ausgeblendet werden.
1. Nginx absichern
Fügen Sie in der globalen Nginx-Konfigurationsdatei (nginx.conf) im Block http folgende Zeile hinzu. Dies blendet die Versionsnummer aus (es wird nur noch Server: nginx angezeigt):
server_tokens off;
Um den Server-Header komplett zu entfernen, wird das Nginx-Modul headers-more benötigt:
more_clear_headers 'Server';
more_clear_headers 'X-Powered-By';
2. Apache absichern
In der Apache-Konfiguration (httpd.conf oder security.conf) steuern folgende Direktiven die Ausgabe:
ServerTokens ProductOnly
ServerSignature Off
Dies reduziert den Header auf Server: Apache und deaktiviert die Signatur auf Server-Fehlerseiten (404/500). Achten Sie darauf, dass die Direktiven im globalen Kontext stehen, damit sie auch für Fehlerseiten und alle virtuellen Hosts greifen.
3. Applikations-Server (PHP/Java/Express.js) absichern
- PHP: Deaktivieren Sie das Flag in der
php.ini:expose_php = Off - Express.js (Node.js): Blenden Sie den Header im Code aus:
app.disable('x-powered-by'); - Spring Boot (Java): Kann im Embedded Tomcat oder im vorgeschalteten Nginx-Reverse-Proxy geregelt werden.
4. Reverse-Proxy und CDN als zentrale Stelle
In modernen Architekturen sitzt häufig ein Reverse-Proxy (z. B. Nginx, Traefik) oder ein CDN vor der eigentlichen Anwendung. Diese Schicht eignet sich ideal, um Informations-Header zentral zu bereinigen, statt sie in jeder einzelnen Anwendung zu konfigurieren. Ein einziges proxy_hide_header- oder more_clear_headers-Statement entfernt dann verräterische Header für sämtliche dahinterliegenden Dienste – das reduziert Wartungsaufwand und verhindert, dass eine vergessene Anwendung doch wieder ihre Version preisgibt.
[!TIP] Die Anonymisierung der Server-Ausgaben ist die absolute Basis-Schutzmassnahme bei jedem Server-Setup. Prüfen Sie, ob Ihr Server sensible Versionsdetails preisgibt, mit dem Security Header Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Ist die Deaktivierung des Server-Headers eine absolute Sicherheitsgarantie?
Nein, das Entfernen der Header ist eine reine Härtungsmassnahme (Security through Obscurity). Sie verhindert automatisiertes Scannen nach Schwachstellen, schützt aber nicht vor gezielten Angriffen auf Applikationsebene.
Was ist der „X-Powered-By“ Header?
Dieser Header wird von Anwendungs-Servern oder Frameworks (z. B. PHP, Express.js, ASP.NET) generiert. Er zeigt an, mit welcher Programmiersprache oder welchem Web-Framework die Website im Backend betrieben wird.
Welche weiteren Header verraten ungewollt interne Details?
Neben `Server` und `X-Powered-By` plaudern auch `X-AspNet-Version`, `X-AspNetMvc-Version`, `X-Runtime`, `X-Generator` (z. B. von CMS) und teils `Via`-Header interne Versionen oder eingesetzte Software aus. Prüfen Sie die gesamte Antwort und entfernen Sie alle nicht funktional notwendigen Informations-Header.
Schadet das Entfernen des Server-Headers der Kompatibilität?
Nein. Der `Server`-Header ist rein informativ; Browser und Clients benötigen ihn nicht zur korrekten Verarbeitung der Antwort. Sie können ihn gefahrlos auf einen generischen Wert reduzieren oder ganz entfernen, ohne dass Funktionen ausfallen.