Cookie-Sicherheit für Apache konfigurieren

Schritt-für-Schritt-Anleitung: Secure, HttpOnly und SameSite auf Apache einrichten — per php.ini, .htaccess und mod_headers mit IfModule-Wrapper. Auch für Shared Hosting ohne Root-Zugriff.

Cookies prüfen Plattform entdecken
Apache · Schritt für Schritt
Von Wolf-Agents Security Team · Aktualisiert: 16. März 2026

Sichere Cookies auf Apache

Apache ist oft auf Shared Hosting anzutreffen — ohne Root-Zugriff auf die Serverkonfiguration. Die gute Nachricht: php.ini und .htaccess reichen für sichere Session-Cookies aus. Beide Methoden setzen Cookie-Flags direkt an der Quelle und umgehen die typischen Regex-Probleme von mod_headers.

Diese Anleitung zeigt die Konfiguration in vier Schritten: vom Setzen der Flags per php.ini über .htaccess als Shared-Hosting-Alternative bis zu Cookie-Prefixes und der Verifizierung. Der IfModule-Wrapper für mod_headers wird als ergänzende Technik erklärt — nicht als Ersatz. Cookie-Sicherheit ist mit 15 von 166 Punkten ein wichtiger Faktor im Wolf-Agents Web Security Check.

Ausführliche Einführung in Cookie-Sicherheit

1 Schritt 1 von 4

PHP-Konfiguration (php.ini) — die sicherste Methode

Die direkteste und zuverlässigste Methode ist die PHP-Konfiguration über php.ini. Sie setzt Cookie-Flags an der Quelle — bevor Apache sie überhaupt sieht. Keine Regex, keine doppelten Flags, keine Überraschungen. Erfordert Root-Zugriff auf den Server.

/etc/php/8.x/apache2/php.ini Empfohlen 
; php.ini — empfohlene Session-Cookie-Einstellungen
session.cookie_secure     = 1
session.cookie_httponly   = 1
session.cookie_samesite   = Strict
session.use_only_cookies  = 1
session.use_strict_mode   = 1
PHP-Version prüfen

session.cookie_samesite ist erst ab PHP 7.3 verfügbar. Prüfen Sie mit php -v, welche Version aktiv ist. Der php.ini-Pfad variiert je nach Distribution: /etc/php/8.x/apache2/php.ini (Debian/Ubuntu) oder /etc/php.ini (RHEL/CentOS).

Apache nach php.ini-Änderung neu laden: 
sudo systemctl reload apache2
2 Schritt 2 von 4

.htaccess als Alternative (Shared Hosting)

Ohne Root-Zugriff auf die Serverkonfiguration ist .htaccess die empfohlene Alternative. php_value-Direktiven setzen PHP-INI-Werte auf Verzeichnisebene — kein Neustart erforderlich, die Datei wird bei jedem Request neu eingelesen. PHP 7.3+ ist Voraussetzung für session.cookie_samesite.

.htaccess (im Wurzelverzeichnis der Anwendung) Shared Hosting 
# .htaccess — PHP-Cookie-Flags (PHP 7.3+ erforderlich für SameSite)
# Gilt nur für dieses Verzeichnis und Unterordner

php_value session.cookie_secure   1
php_value session.cookie_httponly  1
php_value session.cookie_samesite  Strict
Die häufig empfohlene Methode Header always edit Set-Cookie mit Regex kann doppelte Flags erzeugen (z.B. SameSite=Lax; SameSite=Strict), wenn das Flag bereits vorhanden ist. Verwenden Sie stattdessen die PHP-ini-Konfiguration aus Schritt 1 oder setzen Sie Cookies direkt in Ihrer Anwendung.
mod_headers — nur als Ergänzung (kein PHP) Fallback 
# apache2.conf / httpd.conf — nur als Ergänzung, NICHT als Ersatz für php.ini
# IfModule-Wrapper: Apache startet auch ohne mod_headers
<IfModule mod_headers.c>
    # Warnung: "Header always edit" mit Regex kann doppelte SameSite-Werte erzeugen.
    # Verwenden Sie stattdessen php.ini (Schritt 1) oder .htaccess (Schritt 2).
    # Nur nutzen, wenn Set-Cookie-Header von einer anderen Anwendung kommt (kein PHP).
    Header always edit Set-Cookie "^(.*)$" "$1; Secure; HttpOnly; SameSite=Strict"
</IfModule>
Methode Root nötig Neustart nötig Empfehlung
php.ini Ja Ja (reload) Beste Methode — zuverlässig, keine Regex
.htaccess Nein Nein Shared Hosting — PHP 7.3+ erforderlich
mod_headers Ja Ja (reload) Nur für Non-PHP-Apps, mit Vorsicht
3 Schritt 3 von 4

Cookie-Prefixes und Best Practices

Cookie-Prefixes sind ein zusätzlicher Defense-in-Depth-Mechanismus: Der Browser erzwingt Attribute allein aufgrund des Cookie-Namens. __Host- ist die strengste Option — sie verbietet das Domain-Attribut und erzwingt Secure und Path=/. Auf Apache werden Prefixes im PHP-Code gesetzt, nicht in php.ini oder .htaccess.

PHP-Anwendungscode Prefixes 
# Cookie-Prefixes werden im PHP-Code gesetzt, nicht in php.ini
# Beispiel: Session-Cookie mit __Host- Prefix (stärkste Option)

// PHP-Code (z.B. in session_start-Wrapper)
session_set_cookie_params([
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Strict',
    'path'     => '/',
]);

// Eigener Session-Name mit __Host- Prefix
session_name('__Host-session');
session_start();

// Ergebnis: Set-Cookie: __Host-session=...; Secure; Path=/; HttpOnly; SameSite=Strict
/etc/php/8.x/apache2/php.ini — SameSite-Optionen SameSite 
; php.ini — SameSite-Optionen im Vergleich

; Strict: Cookie wird NIE bei Cross-Site-Requests gesendet
; → für Admin-Panels, Banking, hochsensible Anwendungen
session.cookie_samesite = Strict

; Lax: Cookie bei Top-Level-GET-Navigation erlaubt
; → empfohlen für die meisten Websites (Standard ab PHP 8.0)
session.cookie_samesite = Lax

; None: Cookie immer gesendet — benötigt zwingend Secure
; → nur für Cross-Site-Embeds (Zahlungs-iFrames etc.)
session.cookie_samesite = None
Wert Cross-Site-Verhalten Empfehlung
Strict Cookie wird nie bei Cross-Site-Requests gesendet Banking, Admin-Panels, sensitive APIs
Lax Cookie wird bei Top-Level-GET-Navigation gesendet Standard für die meisten Websites
None Cookie wird immer gesendet (benötigt Secure) Nur für Cross-Site-Embeds / iFrames
Bei E-Commerce-Shops auf Apache mit Payment-Providern (Stripe, PayPal): Verwenden Sie SameSite=Lax — Redirect-Returns von Payment-Seiten verlieren sonst die Session bei SameSite=Strict.
4 Schritt 4 von 4

Konfiguration verifizieren

Nach dem Reload prüfen Sie, ob die Cookie-Flags korrekt gesetzt werden. Nutzen Sie curl für einen schnellen Check, phpinfo() für die PHP-Einstellungen und die Browser DevTools (Application → Cookies) für eine visuelle Prüfung aller Cookie-Attribute.

Terminal Verifizierung 
# 1. Apache-Konfiguration prüfen (nach httpd.conf-Änderungen)
sudo apachectl configtest

# 2. Apache neu laden (ohne Downtime)
sudo systemctl reload apache2    # Debian/Ubuntu
sudo systemctl reload httpd      # RHEL/CentOS/AlmaLinux

# 3. Cookie-Flags per curl verifizieren
curl -sI https://ihre-domain.de/login | grep -i set-cookie

# Erwartete Ausgabe:
# Set-Cookie: PHPSESSID=...; Secure; HttpOnly; SameSite=Strict

# 4. PHP-Einstellungen prüfen (temporäre Datei — danach sofort löschen!)
# Erstellen: echo '<?php phpinfo(); ?>' > /var/www/html/info.php
# Im Browser öffnen und nach "session.cookie_secure" suchen
# DANACH: rm /var/www/html/info.php
Browser DevTools als Alternative

Öffnen Sie DevTools (F12) → Application → Cookies → Ihre Domain. Prüfen Sie die Spalten HttpOnly, Secure und SameSite für jeden Cookie. Session-Cookies müssen bei allen drei Spalten ein Häkchen zeigen.

Auch verfügbar für:

NginxWordPressNext.jsCloudflareExpressCaddyShopifyDemnächstTYPO3DemnächstHetznerDemnächstLaravelDemnächstDrupalDemnächstIONOSDemnächstAll-InklDemnächstShopwareDemnächstContaoDemnächstStratoDemnächstJoomlaDemnächstPHPDemnächstSpring BootDemnächst

Wie steht Ihre Domain bei Cookie-Sicherheit?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Warum ist php.ini besser als mod_headers für Cookie-Flags auf Apache?

Die Methode mit mod_headers und "Header always edit Set-Cookie" verwendet reguläre Ausdrücke, die doppelte Flags erzeugen können — z.B. "SameSite=Lax; SameSite=Strict" — wenn das Flag bereits von der Anwendung gesetzt wurde. php.ini dagegen steuert die Cookie-Generierung direkt an der Quelle und ist damit zuverlässiger und einfacher zu debuggen.

Was ist der Unterschied zwischen php.ini und .htaccess für Cookie-Konfiguration?

php.ini gilt serverübergreifend für alle PHP-Anwendungen auf dem Server — dafür brauchen Sie Root-Zugriff. .htaccess-Einstellungen (php_value session.cookie_secure 1) gelten nur für das jeweilige Verzeichnis und dessen Unterordner. Auf Shared Hosting ohne Root-Zugriff ist .htaccess oft die einzige Option. Beide Methoden erfordern PHP 7.3+ für session.cookie_samesite.

Wozu dient der IfModule-Wrapper in Apache-Konfigurationen?

Der IfModule-Wrapper (z.B. <IfModule mod_headers.c>) verhindert, dass Apache mit einem Fehler startet, wenn das jeweilige Modul nicht geladen ist. Auf Shared Hosting oder minimalen Apache-Installationen kann mod_headers fehlen. Der IfModule-Wrapper macht die Konfiguration robuster — der Server startet auch ohne das Modul, setzt dann aber keine Header.

Muss ich Apache nach Änderungen in .htaccess neu starten?

Nein. .htaccess-Dateien werden von Apache bei jedem Request neu eingelesen — ein Neustart oder Reload ist nicht erforderlich. Bei Änderungen in der Haupt-Konfigurationsdatei (httpd.conf oder apache2.conf) sowie bei php.ini-Änderungen müssen Sie Apache neu laden: sudo systemctl reload apache2 (Debian/Ubuntu) oder sudo systemctl reload httpd (RHEL/CentOS).

Funktioniert session.cookie_samesite auf allen PHP-Versionen?

Nein. Das Attribut session.cookie_samesite wurde erst mit PHP 7.3 eingeführt. Auf älteren PHP-Versionen (7.0, 7.1, 7.2) müssen Sie SameSite entweder direkt im Anwendungscode setzen (z.B. über setcookie() mit dem options-Array in PHP 7.3+) oder mod_headers als Fallback nutzen. Prüfen Sie Ihre PHP-Version mit php -v.

Wie prüfe ich, ob meine php.ini-Einstellungen aktiv sind?

Erstellen Sie eine temporäre Testdatei mit <?php phpinfo(); ?> und rufen Sie sie im Browser auf. Suchen Sie nach "session.cookie_secure", "session.cookie_httponly" und "session.cookie_samesite" — die Spalte "Local Value" zeigt den aktiven Wert. Entfernen Sie die Testdatei danach sofort, da phpinfo() sensible Serverinformationen offenbart.

Kann ich mod_headers und php.ini gleichzeitig verwenden?

Ja, aber es ist nicht empfehlenswert. Wenn php.ini bereits Secure und HttpOnly setzt und mod_headers dieselben Flags nochmals hinzufügt, entstehen keine Duplikate bei diesen binären Flags — aber bei SameSite kann es je nach Apache-Version und Konfiguration zu doppelten Werten kommen. Verwenden Sie eine einzige Methode: php.ini ist die zuverlässigere Wahl.