---
url: 'https://sithis.xyz/blog/der-tuersteher-fuer-deine-domain-trusted-host-settings'
title: 'Level 12: Der Türsteher für deine Domain (Trusted Host Settings)'
author:
  name: 'Joachim Namyslo'
  url: 'https://sithis.xyz/team/joachim'
  sameAs:
    - 'https://www.youtube.com/@jo_de'
    - 'https://github.com/nodedropweb'
    - 'https://www.drupal.org/u/Joachim-Namyslo'
date: '2026-08-29T21:13:31+00:00'
updated: '2026-08-30T16:29:49+00:00'
type: article
summary: 'Host-Header-Spoofing kann gefälschte Passwort-Reset-Links erzeugen: So schützt du deine Drupal-Seite mit trusted_host_patterns in der settings.php.'
tags:
  - settings-php
  - sicherheit
image: 'https://sithis.xyz/sites/default/files/2026-08/Trusted-host-settings-in-Drupal_0.png'
published: true
og:
  site_name: 'Drupal TV'
  updated_time: '2026-08-30T18:29:49+02:00'
---
# Level 12: Der Türsteher für deine Domain (Trusted Host Settings)

 

## Key Facts

- Eine rote Warnmeldung im Drupal-Statusbericht zu trusted\_host\_patterns bedeutet: diese Einstellung fehlt noch
- Ohne sie können Angreifer deiner Seite vorgaukeln, sie sei eine andere Domain ("Host Header Spoofing") – das führt zu gefälschten Links in Passwort-Reset-Mails
- Eine einfache Whitelist in der settings.php sagt Drupal, nur auf Anfragen an deine echte Domain zu antworten
- Die Konfiguration nutzt reguläre Ausdrücke (Regex) – hier sind fertige Vorlagen für Live, Localhost und DDEV zum Kopieren

## Das Szenario: Identitätsdiebstahl per E-Mail

Warum ist das gefährlich? Ein Angreifer sendet eine Anfrage an deine Seite, behauptet aber im Header, er sei böse-seite.de. Deine Drupal-Seite glaubt das, weil der Türsteher fehlt. Fordert ein Nutzer zeitgleich ein neues Passwort an, generiert Drupal den Reset-Link mit der falschen Domain: <http://böse-seite.de/user/reset/>.... Klickt der Nutzer darauf, landet sein neues Passwort direkt beim Angreifer.

Damit das nicht passiert, bringen wir Drupal bei, nur auf deine echte Domain zu hören.

## Die settings.php bearbeiten

Öffne /sites/default/settings.php und suche den Abschnitt $settings\['trusted\_host\_patterns'\]. Konfiguriert wird über reguläre Ausdrücke – sieht kryptisch aus, ist aber logisch:

| Zeichen | Bedeutung | Beispiel |
|---|---|---|
| ^ | Start: Hier beginnt die Domain | ^drupal |
| $ | Ende: Hier hört sie auf | de$ |
| \\. | Ein echter Punkt (muss maskiert werden) | google\\.de |
| .+ | Platzhalter, z. B. für Subdomains | ^.+\\.seite\\.de$ |

### 1. Live-Szenario (Production)

Deine Hauptdomain (example.com) und die www-Variante erlauben:

$settings\['trusted\_host\_patterns'\] = \[  
 '^example\\.com$',  
 '^www\\.example\\.com$',  
\];

### 2. Beliebige Subdomains erlauben

Du hast viele Subdomains (blog., shop., team.) und willst nicht jede einzeln eintragen:

$settings\['trusted\_host\_patterns'\] = \[  
 '^example\\.com$',  
 '^.+\\.example\\.com$',  
\];

### 3. Entwicklungsumgebung (DDEV / Localhost)

Lokal ändern sich URLs häufig. Für Localhost (XAMPP/MAMP):

$settings\['trusted\_host\_patterns'\] = \[  
 '^localhost$',  
 '^127\\.0\\.0\\.1$',  
\];

Für DDEV, das Domains wie mein-projekt.ddev.site nutzt, deckt dieser Eintrag alles ab:

$settings\['trusted\_host\_patterns'\] = \[  
 // Erlaubt alles, was auf .ddev.site endet  
 '^.+\\.ddev\\.site$',  
\];

## Der Check: Ist die Anzeige grün?

Speichere die settings.php, gehe im Drupal-Backend zu Berichte → Statusbericht und suche die Zeile "Einstellungen für vertrauenswürdige Hosts". Ist sie grün, ist dein Türsteher aktiv und deine Nutzer sind geschützt.

**Fazit:** Die Trusted Host Settings sind kein Bürokratie-Posten, sondern ein essenzieller Sicherheitsmechanismus. Es dauert zwei Minuten, sie einzurichten – mach es, bevor du live gehst.



Weiterführende Links

[Offizielle Drupal-Dokumentation – Trusted Host settings](https://www.drupal.org/docs/getting-started/installing-drupal/trusted-host-settings)

[Host Header Attacks erklärt (PortSwigger)](https://portswigger.net/web-security/host-header)

[OWASP Guide zu Host Header Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection)