Technik
Wenn Sicherheitsvorgaben deine Werbung ausbremsen.
Es gibt einen Fall, der Kunden regelmäßig ratlos zurücklässt: Die Kampagne läuft, die Statistik zählt, aber auf der eigenen Seite kommt sichtbar nichts an — oder der Werberahmen bleibt einfach weiß. Dahinter steckt oft kein Fehler in der Kampagne, sondern ein Schutzmechanismus auf dem eigenen Webserver: die Content Security Policy, kurz CSP, und ihr älterer Verwandter X-Frame-Options. Beide sind sinnvoll und schützen vor echten Angriffen. Sie unterscheiden nur leider nicht immer zwischen bösartigem Code und einer regulären Werbeauslieferung.
Was die Content Security Policy macht
Die Idee dahinter ist einfach: Dein Webserver schickt beim Ausliefern der Seite zusätzliche Angaben mit, die dem Browser sagen, was er laden darf und was nicht. Der Browser hält sich daran — ausnahmslos.
Das verhindert wirksam, dass fremder Code in deine Seite eingeschleust wird. Es kann aber genauso Werbe- und Marketingmaßnahmen treffen, weil auch die technisch gesehen Inhalte von einem anderen Server nachladen.
Was in der Praxis passieren kann
- Der Browser lädt bestimmte JavaScript-Dateien nicht mehr und führt sie nicht aus
- Ein eingebundener Bereich bleibt leer, die Seite darin weiß
- Verbindungen werden von vornherein abgelehnt, wenn sie nicht exakt vom selben Server stammen wie die Seite
- Die Messung deines eigenen Analyse-Tools fällt aus, weil dessen Skript blockiert wird
Wo die Vorgaben herkommen
CSP lässt sich an drei Stellen setzen — und häufig weiß der Seitenbetreiber gar nicht, dass eine davon aktiv ist. Gerade bei fertigen Systemen und Sicherheits-Erweiterungen ist sie oft voreingestellt.
- Konfiguration des Webservers: als HTTP-Header, etwa in der Serverkonfiguration oder einer .htaccess
- Serverseitige Skriptsprache: der Header wird beim Ausliefern im Code gesetzt
- Meta-Element im HTML-Kopf: die einfachste Variante, aber nur wirksam, solange der Server keinen eigenen Header schickt — der hätte nämlich Vorrang
Eine Angabe wie default-src 'self' bedeutet, dass grundsätzlich nur Inhalte vom eigenen Server geladen werden dürfen. script-src 'self' beschränkt dasselbe auf JavaScript — und hat einen Nebeneffekt, den viele übersehen: Auch Skriptcode, der direkt im HTML steht, wird damit blockiert.
X-Frame-Options: der ältere Verwandte
Diese Vorgabe regelt eine einzige Frage: Darf deine Seite innerhalb eines Rahmens auf einer anderen Seite dargestellt werden? Steht dort DENY, lautet die Antwort nein — unter allen Umständen.
Das schützt davor, dass jemand deine Seite unsichtbar hinter seine eigene legt und Klicks abgreift. Es bedeutet aber auch, dass Werbeformen, die mit einem Rahmen arbeiten, deine Website nicht öffnen können. Dasselbe gilt für Skripte, die ein Verlassen des Rahmens erzwingen — sogenannte Framekiller.
Was sich dagegen tun lässt
Die gute Nachricht: Das ist lösbar, und zwar ohne den Schutz aufzugeben. Nötig sind Änderungen am HTML-Code, am Skript oder an der Konfiguration deines Webservers — je nachdem, wo die Vorgabe gesetzt wird.
- Prüfe zuerst, ob überhaupt ein CSP-Header gesendet wird — oft ist er unbemerkt aktiv
- Erweitere die Vorgaben gezielt um die benötigten Quellen, statt sie pauschal abzuschalten
- Achte bei X-Frame-Options auf den Wert: DENY ist die strengste Einstellung
- Frag im Zweifel deinen Webhoster oder deine Webagentur — für beide ist das Routine
Wenn du unsicher bist, ob deine Website geeignet ist: Sprich uns vor der Buchung an. Ein kurzer Blick vorab erspart Diskussionen hinterher.
Häufig gefragt
Fragen zu CSP und Rahmen-Vorgaben
Woran merke ich, dass CSP meine Kampagne blockiert?
Muss ich CSP abschalten, um Werbung zu schalten?
Wo wird CSP überhaupt eingestellt?
Was hat X-Frame-Options damit zu tun?
Weiterlesen