Cross-Origin Headers für Apache
COOP, CORP und optional COEP auf Apache einrichten — mit mod_headers, .htaccess-Konfiguration und differenzierter Steuerung nach Ressourcentyp.
Cross-Origin Headers auf Apache
Apache HTTP Server setzt Cross-Origin Headers über das mod_headers-Modul — sowohl in der VirtualHost-Konfiguration als auch in .htaccess-Dateien. Das macht Apache zur flexibelsten Option, besonders auf Shared Hosting, wo Sie keinen Zugriff auf die Serverkonfiguration haben.
Diese Anleitung zeigt die Implementierung in drei Schritten: COOP für Fenster-Isolation, CORP differenziert nach Ressourcentyp mit FilesMatch, und optional COEP für vollständige Cross-Origin Isolation. Der IfModule-Wrapper stellt sicher, dass die Konfiguration auch ohne mod_headers fehlerfrei bleibt. Cross-Origin Headers bringen 30 von 166 Punkten im Wolf-Agents Web Security Check.
COOP konfigurieren — Fenster-Isolation aktivieren
Cross-Origin-Opener-Policy isoliert Ihr Browser-Fenster von anderen Tabs und Popups. Setzen Sie den Header in .htaccess oder der VirtualHost-Konfiguration mit mod_headers. Der IfModule-Wrapper verhindert Fehler, falls das Modul nicht geladen ist.
<IfModule mod_headers.c>
# Cross-Origin-Resource-Policy
# Für öffentliche Ressourcen:
Header always set Cross-Origin-Resource-Policy "cross-origin"
# Oder für geschützte Ressourcen:
# Header always set Cross-Origin-Resource-Policy "same-origin"
# Cross-Origin-Embedder-Policy
# Vorsicht: Kann externe Ressourcen blockieren!
# Header always set Cross-Origin-Embedder-Policy "require-corp"
# Cross-Origin-Opener-Policy
Header always set Cross-Origin-Opener-Policy "same-origin-allow-popups"
</IfModule>IfModule? Der IfModule mod_headers.c-Wrapper prüft, ob das Modul geladen ist. Ohne den Wrapper bricht Apache mit einem 500-Fehler ab, wenn mod_headers nicht installiert ist — besonders relevant auf Shared Hosting.
same-origin-allow-popups vs. same-origin Mit same-origin-allow-popups funktionieren OAuth-Flows (Google, GitHub Login) und Payment-Popups weiterhin. same-origin bietet maximale Isolation, kann aber solche Flows brechen.
CORP hinzufügen — Ressourcen-Zugriff kontrollieren
Cross-Origin-Resource-Policy kontrolliert, welche Origins Ihre Ressourcen laden dürfen. Apache erlaubt mit FilesMatch und Location differenzierte Konfiguration nach Dateityp und Pfad.
# Bilder für alle freigeben
<FilesMatch "\.(jpg|jpeg|png|gif|webp|svg)$">
Header set Cross-Origin-Resource-Policy "cross-origin"
</FilesMatch>
# APIs nur für same-origin
<Location "/api/">
Header set Cross-Origin-Resource-Policy "same-origin"
</Location>CORP-Werte im Überblick
same-origin
Nur die eigene Origin darf die Ressource laden. Maximal restriktiv — ideal für APIs und sensible Daten.
same-site
Alle Subdomains der gleichen Site dürfen laden. Guter Kompromiss für die meisten Websites mit Subdomains.
cross-origin
Jede Origin darf die Ressource laden. Für öffentliche Assets wie Bilder, CSS und JavaScript auf CDNs.
Location-Direktiven funktionieren nur in der VirtualHost-Konfiguration, nicht in .htaccess. Für .htaccess verwenden Sie FilesMatch und SetEnvIf. COEP optional aktivieren und testen
Für vollständige Cross-Origin Isolation setzen Sie alle drei Header zusammen. COEP mit require-corp erzwingt, dass alle eingebetteten Ressourcen einen CORP- oder CORS-Header senden. Nur aktivieren, wenn Sie SharedArrayBuffer benötigen.
<IfModule mod_headers.c>
Header always set Cross-Origin-Opener-Policy "same-origin"
Header always set Cross-Origin-Embedder-Policy "require-corp"
Header always set Cross-Origin-Resource-Policy "same-origin"
</IfModule>require-corp blockiert alle externen Ressourcen ohne CORP- oder CORS-Header — darunter Google Fonts, YouTube-Embeds, Google Maps und CDN-Bilder. Testen Sie gründlich, bevor Sie COEP aktivieren. # Cross-Origin Header prüfen
curl -sI https://example.com | grep -i cross-origin
# Erwartete Ausgabe:
# cross-origin-opener-policy: same-origin-allow-popups
# cross-origin-resource-policy: cross-originAuf Debian/Ubuntu aktivieren Sie mod_headers mit sudo a2enmod headers && sudo systemctl reload apache2. Auf den meisten Shared-Hosting-Anbietern ist das Modul bereits aktiv.
Wie steht Ihre Domain bei Cross-Origin Headers?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Warum brauche ich den IfModule-Wrapper bei Apache?
Der IfModule-Wrapper prüft, ob mod_headers geladen ist, bevor die Header-Direktiven verarbeitet werden. Ohne den Wrapper bricht Apache mit einem Fehler ab, wenn mod_headers nicht installiert ist — besonders relevant auf Shared Hosting, wo Sie die Module nicht selbst kontrollieren.
Kann ich CORP mit FilesMatch differenziert setzen?
Ja. Apache erlaubt mit FilesMatch unterschiedliche Cross-Origin-Resource-Policy-Werte nach Dateityp: "cross-origin" für Bilder und öffentliche Assets, "same-origin" für APIs und sensible Daten. So schützen Sie sensible Endpunkte, ohne öffentliche Ressourcen zu blockieren.
Funktioniert die Konfiguration in .htaccess und VirtualHost?
Ja. Alle gezeigten Konfigurationen funktionieren sowohl in .htaccess als auch in VirtualHost-Blöcken. Auf Shared Hosting verwenden Sie .htaccess, auf dedizierten Servern ist die VirtualHost-Konfiguration performanter, da .htaccess-Dateien bei jedem Request gelesen werden.
Was passiert, wenn ich COEP auf require-corp setze?
COEP mit require-corp blockiert alle externen Ressourcen ohne CORP- oder CORS-Header — darunter Google Fonts, YouTube-Embeds, Google Maps und CDN-Bilder. Aktivieren Sie COEP erst nach gründlichem Testen oder verwenden Sie credentialless als Alternative.
Brauche ich alle drei Cross-Origin Headers?
Nein. COOP und CORP sind einzeln einsetzbar und risikoarm. Starten Sie mit COOP (same-origin-allow-popups) und CORP (cross-origin oder same-site). COEP wird nur benötigt, wenn Sie SharedArrayBuffer oder vollständige Cross-Origin Isolation brauchen.
Muss ich Apache nach der Änderung neu starten?
Bei Änderungen in der VirtualHost-Konfiguration genügt ein Reload: systemctl reload apache2. Bei .htaccess-Änderungen ist kein Neustart nötig — Apache liest .htaccess bei jedem Request neu ein.