[{"data":1,"prerenderedAt":1035},["ShallowReactive",2],{"blog-post-de-what-is-permissions-policy":3,"related-posts-de-what-is-permissions-policy":171},{"post":4,"slugMap":170},{"id":5,"title":6,"author":7,"body":8,"category":132,"date":133,"description":134,"extension":135,"faq":136,"meta":158,"navigation":159,"path":160,"readingTime":161,"seo":162,"slug":163,"stem":164,"tags":165,"__hash__":169},"blog\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy.md","Was ist der Permissions-Policy Header und warum ist er wichtig?","EuroraCloud Team",{"type":9,"value":10,"toc":120},"minimark",[11,15,19,24,27,30,34,49,55,59,62,65,69,72,75,79,82,85,88,92,95,98,102,105,113,117],[12,13,6],"h1",{"id":14},"was-ist-der-permissions-policy-header-und-warum-ist-er-wichtig",[16,17,18],"p",{},"Der Permissions-Policy Header ist ein Response-Header, der einer Website erlaubt zu steuern, welche Browserfunktionen ihre eigenen Seiten und alle darin eingebetteten Inhalte nutzen dürfen. Funktionen wie Kamera, Mikrofon, Geolokalisierung und Zahlung können jeweils erlaubt, auf Ihre eigene Origin beschränkt oder ganz abgeschaltet werden. Ihn zu setzen bedeutet, dass der Browser die Nutzung verweigert, selbst wenn ein Skript oder ein eingebetteter Dritter versucht, eine dieser Funktionen zu erreichen, sofern Ihre Richtlinie es nicht erlaubt, was sowohl Ihre Datenschutzangriffsfläche als auch Ihre allgemeine Angriffsfläche verringert.",[20,21,23],"h2",{"id":22},"warum-gibt-es-den-permissions-policy-header","Warum gibt es den Permissions-Policy Header?",[16,25,26],{},"Moderne Browser stellen Webseiten viele leistungsstarke Fähigkeiten bereit: Standort, Kamera, Mikrofon, Bewegungssensoren und mehr. Jedes Skript, das auf Ihrer Seite läuft, einschließlich der Drittanbieter-Skripte, die Sie für Analytics, Chat oder Werbung eingebettet haben, kann den Browser im Prinzip auffordern, diese Fähigkeiten zu nutzen. Permissions-Policy existiert, damit Sie auf Ebene der gesamten Website festlegen können, welche dieser Funktionen erlaubt sind und für wen.",[16,28,29],{},"Der Sinn besteht darin, die Lücke zwischen dem, was ein Browser kann, und dem, was Ihre Website tatsächlich braucht, zu schließen. Die meisten Websites nutzen nie den Beschleunigungssensor oder die Payment-API, doch ohne Richtlinie bleiben diese Funktionen für jeden Code auf der Seite erreichbar. Laut der Dokumentation von MDN wird der Nutzer, wenn eine Richtlinie eine Funktion blockiert, nicht einmal um Erlaubnis gebeten, und der Versuch eines Skripts, sie zu nutzen, scheitert schlicht, was genau die Eindämmung ist, die Sie für Funktionen wünschen, die Sie nie nutzen wollten.",[20,31,33],{"id":32},"was-leistet-der-permissions-policy-header-eigentlich","Was leistet der Permissions-Policy Header eigentlich?",[16,35,36,37,43,44,48],{},"Der Header funktioniert als Liste von Direktiven, eine pro Funktion, jede mit einer Allowlist, die angibt, welche Origins sie nutzen dürfen. Die Syntax ist der Funktionsname, ein Gleichheitszeichen und die erlaubten Origins in Klammern, wobei mehrere Direktiven durch Kommas getrennt werden, zum Beispiel geolocation=(), camera=(self). Eine leere Allowlist, geschrieben als (), schaltet die Funktion überall ab; self erlaubt sie nur auf Ihrer eigenen Origin; eine bestimmte Origin wie (\"",[38,39,40],"a",{"href":40,"rel":41},"https:\u002F\u002Fexample.com",[42],"nofollow","\") erlaubt diese Origin; und ",[45,46,47],"code",{},"*"," erlaubt sie überall, auch in eingebetteten Frames.",[16,50,51,52,54],{},"Ein nützliches Detail ist, dass jede Funktion eine Standard-Allowlist hat, die gilt, wenn Sie nichts angeben, und je nach Funktion ist dieser Standard ",[45,53,47],{},", self oder keine. Der Wert, den Header explizit zu setzen, besteht also darin, dass Sie sich nicht länger auf die Standards je Funktion verlassen, sondern eine bewusste, einheitliche Entscheidung treffen: alles abschalten, was Sie nicht nutzen, und alles, was Sie nutzen, auf Ihre eigene Origin oder die bestimmten Partner beschränken, die es brauchen.",[20,56,58],{"id":57},"wie-verhält-sich-der-header-mit-eingebetteten-iframes","Wie verhält sich der Header mit eingebetteten iframes?",[16,60,61],{},"Das ist der Teil, über den die meisten stolpern, daher lohnt sich Genauigkeit. Eine Funktion ist innerhalb eines eingebetteten iframes nur verfügbar, wenn zwei Bedingungen zugleich erfüllt sind: Ihre Top-Level-Seite muss die Funktion für die Origin dieses Frames in ihrer Permissions-Policy erlauben, und das iframe selbst darf sie nicht deaktiviert haben. Anders gesagt setzt die übergeordnete Seite die äußere Grenze, und nichts Eingebettetes kann sich selbst eine Funktion gewähren, die die übergeordnete Seite vorenthalten hat.",[16,63,64],{},"Es gibt außerdem eine Steuerung je iframe, die neben dem Header wirkt, das allow-Attribut am iframe-Element, zum Beispiel eine eingebettete Karte, hinzugefügt mit einem Frame, dessen allow-Attribut geolocation erlaubt. Das Denkmodell, das Sie behalten sollten, ist, dass der Header die websiteweite Richtlinie ist und das allow-Attribut die Ausnahme je Einbettung darin: Der Frame kann nur erhalten, was der Header bereits erlaubt, und das Attribut grenzt es dann ein oder lenkt es auf diese bestimmte Einbettung. Genau deshalb meldet ein Drittanbieter-Widget manchmal, dass eine Funktion blockiert ist, obwohl der Code des Widgets korrekt ist, weil die enthaltende Seite diese Funktion für die Origin des Widgets nie erlaubt hat.",[20,66,68],{"id":67},"was-passiert-wenn-sie-ihn-nicht-setzen","Was passiert, wenn Sie ihn nicht setzen?",[16,70,71],{},"Ohne den Header fällt jede Funktion auf ihre eigene Standard-Allowlist zurück, die für mehrere Funktionen freizügiger ist, als eine typische Website braucht. In der Praxis bedeutet das, dass Fähigkeiten, die Sie nie nutzen, erreichbar bleiben, und dass eingebettete Drittinhalte Funktionen anfordern können, die Sie nicht gewährt hätten, wenn man Sie gefragt hätte.",[16,73,74],{},"Dies ist meist keine dringende Lücke, weshalb sie unbehandelt bleibt, aber es ist eine echte. Sie wiegt am schwersten dort, wo Sie Code einbetten, den Sie nicht geschrieben haben: ein Analytics-Tag, ein Chat-Widget, ein Marketing-Pixel. Funktionen einzuschränken, die Sie nicht nutzen, verkleinert, was all dieser eingebettete Code versuchen kann, und es ist genau die Art fehlender Header, die Sicherheitsscanner und Audits inzwischen auf fast jeder Website kennzeichnen, die ihn nicht gesetzt hat.",[20,76,78],{"id":77},"wie-implementieren-sie-den-permissions-policy-header","Wie implementieren Sie den Permissions-Policy Header?",[16,80,81],{},"Sie setzen Permissions-Policy als einen einzigen HTTP-Response-Header. Eine sinnvolle Ausgangsrichtlinie besteht darin, die Funktionen abzuschalten, von denen Sie wissen, dass Sie sie nicht nutzen, und den Rest auf Ihre eigene Origin zu beschränken, zum Beispiel Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), und dann einzelne Direktiven nur dort zu lockern, wo ein echter Bedarf besteht. Er kann am Webserver, in der Anwendungsebene oder am Rand in einem CDN oder einer Sicherheitsschicht vor der Website angewendet werden.",[16,83,84],{},"Es hilft, dies an einer echten Website statt im Abstrakten zu betrachten. Nehmen Sie eine Klinik-Website, die eine eingebettete Karte zeigt, damit Patienten die Praxis finden, und ein Online-Buchungstool betreibt, das einen Bezahlschritt öffnet, aber sonst keine Browserfunktionen nutzt. Eine auf diese Website zugeschnittene Richtlinie würde alles abschalten, was sie nie berührt, und nur erlauben, was diese beiden Funktionen brauchen: geolocation beschränkt auf die Origin des Kartenanbieters, payment beschränkt auf den Buchungs- oder Zahlungsanbieter, und Kamera, Mikrofon und die verschiedenen Sensorfunktionen alle mit einer leeren Allowlist abgeschaltet. Das Ergebnis ist eine Seite, auf der Karte und Bezahlvorgang genau wie zuvor funktionieren, während jede andere Fähigkeit für jedes Skript schlicht nicht verfügbar ist, ob dieses Skript Ihres ist oder zu einem eingebetteten Dritten gehört. Das Prinzip lässt sich verallgemeinern: Listen Sie auf, was die Website wirklich nutzt, erlauben Sie diese den bestimmten Origins, die sie bereitstellen, und schließen Sie den Rest.",[16,86,87],{},"Testen Sie, bevor Sie ihn festzurren. Der Header hat einen Report-only-Begleiter, Permissions-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um Ihnen mitzuteilen, was eine Richtlinie blockieren würde, ohne sie tatsächlich durchzusetzen. Diesen zuerst zu betreiben ist der sichere Weg, um herauszufinden, ob eine echte Funktion, eine Karte, die geolocation braucht, ein Buchungstool, das einen Zahlungsablauf öffnet, ein eingebettetes Video, von Ihrer Richtlinie erfasst würde, sodass Sie sie bewusst erlauben, statt sie überraschend zu brechen.",[20,89,91],{"id":90},"was-ändert-sich-auf-ihrer-website-sobald-er-aktiv-ist","Was ändert sich auf Ihrer Website, sobald er aktiv ist?",[16,93,94],{},"Für die meisten Websites nichts Sichtbares. Gewöhnliche Seiten, die keine eingeschränkten Funktionen nutzen, verhalten sich genau wie zuvor, und Besucher bemerken nichts, weil die Richtlinie nur eingreift, wenn Code versucht, eine Funktion zu erreichen, die Sie nicht erlaubt haben.",[16,96,97],{},"Zu prüfen ist jede Funktion, auf die Ihre eigene Website wirklich angewiesen ist, und alles, was Ihre eingebetteten Dritten brauchen. Ein Filialfinder mit Geolokalisierung, eine Videoanruf-Funktion mit Kamera und Mikrofon oder ein Checkout mit der Payment-API müssen alle ihre Direktiven so gesetzt haben, dass die richtigen Origins erlaubt sind, was genau der Grund ist, warum Tests im Report-only-Modus vor der Durchsetzung wichtig sind. Machen Sie das einmal richtig, und der Header hält danach leise die Linie, erlaubt, was Sie beabsichtigt haben, und verweigert alles andere.",[20,99,101],{"id":100},"was-sollten-sie-als-nächstes-tun","Was sollten Sie als Nächstes tun?",[16,103,104],{},"Prüfen Sie zunächst, ob Ihre Website überhaupt einen Permissions-Policy Header sendet, denn ohne ihn fällt jede Funktion schlicht auf ihren Standard zurück. Fehlt er, ist der risikoarme Weg, ihn im Report-only-Modus hinzuzufügen, die Funktionen aufzulisten, die Sie tatsächlich nutzen, zu bestätigen, dass nichts, worauf Sie angewiesen sind, blockiert wird, und dann eine Richtlinie durchzusetzen, die alles andere abschaltet.",[16,106,107,108],{},"Wenn Sie dies über Ihre gesamte Website hinweg korrekt prüfen und konfigurieren lassen möchten statt Stück für Stück, kann EuroraCloud Ihre aktuellen Security Header prüfen und Ihnen zeigen, was unsere Plattform löst. ",[38,109,112],{"href":110,"rel":111},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[42],"Sehen Sie, was EuroraCloud löst",[20,114,116],{"id":115},"fazit-was-sollten-sie-zum-permissions-policy-header-mitnehmen","Fazit: Was sollten Sie zum Permissions-Policy Header mitnehmen?",[16,118,119],{},"Permissions-Policy ist ein leiser, praktischer Header: Er lässt Sie die Browserfunktionen abschalten, die Ihre Website nie nutzt, und jene, die sie nutzt, auf genau die Origins beschränken, die sie brauchen, sodass weder Ihre eigenen Skripte noch eingebettete Dritte Fähigkeiten erreichen können, die Sie nie offenlegen wollten. Der sichere Weg der Einführung ist, im Report-only-Modus zu testen, zu bestätigen, dass Ihre echten Funktionen weiterhin arbeiten, und dann eine Richtlinie durchzusetzen, die den Rest abschaltet. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, bleibt jede Funktion auf ihrem Standard.",{"title":121,"searchDepth":122,"depth":122,"links":123},"",2,[124,125,126,127,128,129,130,131],{"id":22,"depth":122,"text":23},{"id":32,"depth":122,"text":33},{"id":57,"depth":122,"text":58},{"id":67,"depth":122,"text":68},{"id":77,"depth":122,"text":78},{"id":90,"depth":122,"text":91},{"id":100,"depth":122,"text":101},{"id":115,"depth":122,"text":116},"Security Header","2026-07-13","Der Permissions-Policy Header lässt eine Website entscheiden, welche Browserfunktionen, etwa Kamera, Mikrofon und Geolokalisierung, ihre eigenen Seiten und eingebettete Inhalte nutzen dürfen. Das leistet der Header, so setzen Sie ihn, und das ändert sich dadurch.","md",[137,139,141,144,147,149,152,155],{"question":23,"answer":138},"Moderne Browser stellen leistungsstarke Fähigkeiten wie Standort, Kamera, Mikrofon und Bewegungssensoren bereit, und jedes Skript auf Ihrer Seite, einschließlich eingebetteten Drittcodes, kann im Prinzip auffordern, sie zu nutzen. Permissions-Policy existiert, damit Sie auf Websiteebene festlegen können, welche Funktionen erlaubt sind und für wen, und so die Lücke zwischen dem, was ein Browser kann, und dem, was Ihre Website braucht, schließen. Wenn eine Richtlinie eine Funktion blockiert, wird der Nutzer nicht einmal gefragt und der Versuch eines Skripts scheitert schlicht.",{"question":33,"answer":140},"Der Header ist eine Liste von Direktiven, eine pro Funktion, jede mit einer Allowlist von Origins, die sie nutzen dürfen. Die Syntax ist der Funktionsname, ein Gleichheitszeichen und die erlaubten Origins in Klammern, Direktiven durch Kommas getrennt, zum Beispiel geolocation=(), camera=(self). Eine leere Allowlist () schaltet die Funktion überall ab, self erlaubt nur Ihre eigene Origin, eine bestimmte Origin erlaubt diese Origin, und * erlaubt sie überall. Jede Funktion hat zudem eine Standard-Allowlist aus *, self oder keine, die gilt, wenn Sie nichts angeben.",{"question":142,"answer":143},"Wie verhält sich der Permissions-Policy Header mit eingebetteten iframes?","Eine Funktion ist innerhalb eines eingebetteten iframes nur verfügbar, wenn zwei Bedingungen zugleich erfüllt sind: Ihre Top-Level-Seite muss die Funktion für die Origin dieses Frames erlauben, und das iframe selbst darf sie nicht deaktiviert haben. Die übergeordnete Seite setzt die äußere Grenze und nichts Eingebettetes kann sich eine Funktion gewähren, die die übergeordnete Seite vorenthalten hat. Das allow-Attribut am iframe-Element wirkt zusätzlich als Ausnahme je Einbettung: Der Frame kann nur erhalten, was der Header bereits erlaubt.",{"question":145,"answer":146},"Was passiert, wenn Sie den Permissions-Policy Header nicht setzen?","Ohne den Header fällt jede Funktion auf ihre eigene Standard-Allowlist zurück, die für mehrere Funktionen freizügiger ist, als eine typische Website braucht. Fähigkeiten, die Sie nie nutzen, bleiben erreichbar, und eingebettete Drittinhalte können Funktionen anfordern, die Sie nicht gewährt hätten. Es ist selten dringend, weshalb es unbehandelt bleibt, aber es wiegt am schwersten dort, wo Sie Code einbetten, den Sie nicht geschrieben haben, etwa ein Analytics-Tag, Chat-Widget oder Marketing-Pixel, und Scanner kennzeichnen es inzwischen auf fast jeder Website, die ihn nicht gesetzt hat.",{"question":78,"answer":148},"Setzen Sie Permissions-Policy als einen einzigen HTTP-Response-Header, am Webserver, in der Anwendungsebene oder am Rand. Eine sinnvolle Ausgangsrichtlinie schaltet Funktionen ab, die Sie nicht nutzen, und beschränkt den Rest auf Ihre eigene Origin, zum Beispiel geolocation=(), camera=(), microphone=(), payment=(). Testen Sie zuerst mit dem Report-only-Begleiter, Permissions-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um mitzuteilen, was eine Richtlinie blockieren würde, ohne sie durchzusetzen, sodass Sie echte Funktionen bewusst erlauben, statt sie überraschend zu brechen.",{"question":150,"answer":151},"Was ändert sich auf Ihrer Website, sobald der Permissions-Policy Header aktiv ist?","Für die meisten Websites ändert sich nichts Sichtbares, weil die Richtlinie nur eingreift, wenn Code versucht, eine Funktion zu erreichen, die Sie nicht erlaubt haben. Zu prüfen ist jede Funktion, auf die Ihre Website angewiesen ist, und alles, was Ihre eingebetteten Dritten brauchen, etwa ein Filialfinder mit Geolokalisierung, eine Videofunktion mit Kamera und Mikrofon oder ein Checkout mit der Payment-API, die alle ihre Direktiven so gesetzt haben müssen, dass die richtigen Origins erlaubt sind. Deshalb sind Tests im Report-only-Modus vor der Durchsetzung wichtig.",{"question":153,"answer":154},"Was sollten Sie als Nächstes zum Permissions-Policy Header tun?","Prüfen Sie, ob Ihre Website überhaupt einen Permissions-Policy Header sendet, denn ohne ihn fällt jede Funktion auf ihren Standard zurück. Fehlt er, fügen Sie ihn im Report-only-Modus hinzu, listen Sie die Funktionen auf, die Sie tatsächlich nutzen, bestätigen Sie, dass nichts, worauf Sie angewiesen sind, blockiert wird, und setzen Sie dann eine Richtlinie durch, die alles andere abschaltet.",{"question":156,"answer":157},"Was sollten Sie zum Permissions-Policy Header mitnehmen?","Permissions-Policy lässt Sie die Browserfunktionen abschalten, die Ihre Website nie nutzt, und jene, die sie nutzt, auf genau die Origins beschränken, die sie brauchen, sodass weder Ihre eigenen Skripte noch eingebettete Dritte Fähigkeiten erreichen können, die Sie nie offenlegen wollten. Der sichere Weg der Einführung ist, im Report-only-Modus zu testen, zu bestätigen, dass Ihre echten Funktionen weiter arbeiten, und dann eine Richtlinie durchzusetzen, die den Rest abschaltet. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, bleibt jede Funktion auf ihrem Standard.",{},true,"\u002Fblog\u002Fde\u002Fwhat-is-permissions-policy","8 Minuten",{"title":6,"description":134},"what-is-permissions-policy","blog\u002Fde\u002Fwhat-is-permissions-policy",[166,132,167,168],"Permissions-Policy","Web-Sicherheit","Datenschutz","q_cuWTHT0Fwcy2g5TuANtLH4yPhjojwSRC4DGe-ej4c",{"de":163,"en":163,"es":163,"fr":163,"it":163,"nl":163},[172,287,401],{"id":173,"title":174,"author":7,"body":175,"category":258,"date":133,"description":259,"extension":135,"faq":260,"meta":275,"navigation":159,"path":276,"readingTime":277,"seo":278,"slug":279,"stem":280,"tags":281,"__hash__":286},"blog\u002Fblog\u002Fde\u002Fwhat-is-a-ddos-attack.md","Was ist ein DDoS-Angriff und wie schützt man eine Website davor?",{"type":9,"value":176,"toc":250},[177,180,183,187,195,198,202,205,208,211,215,218,221,225,228,231,233,236,243,247],[12,178,174],{"id":179},"was-ist-ein-ddos-angriff-und-wie-schützt-man-eine-website-davor",[16,181,182],{},"Ein DDoS-Angriff (Distributed Denial of Service) versucht, eine Website offline zu nehmen, indem er sie mit weit mehr Datenverkehr überflutet, als sie verarbeiten kann, gleichzeitig gesendet von zahlreichen Rechnern, bis echte Besucher nicht mehr durchkommen. Der Schutz davor besteht darin, diesen bösartigen Datenverkehr herauszufiltern, bevor er Ihren Server erreicht, mithilfe einer Mitigationsschicht, die vor der Website liegt und den Angriff absorbiert oder blockiert. Das praktische Ziel ist einfach: die Website für echte Nutzer verfügbar zu halten, auch während ein Angriff läuft.",[20,184,186],{"id":185},"was-ist-ein-ddos-angriff","Was ist ein DDoS-Angriff?",[16,188,189,190,194],{},"Ein Denial-of-Service-Angriff zielt darauf ab, eine Website oder einen Dienst unerreichbar zu machen. Ein ",[191,192,193],"em",{},"Distributed","-Denial-of-Service-Angriff tut dasselbe von vielen Quellen gleichzeitig, oft Tausende kompromittierte Geräte, die gemeinsam als Botnet agieren, was es weit schwieriger macht, ihn durch das bloße Sperren einer einzelnen Adresse zu stoppen. Der Datenverkehr ist darauf ausgelegt, etwas Endliches zu erschöpfen: die Verbindungen des Servers, seine Verarbeitungskapazität oder die Bandbreite des Netzwerks, in dem er läuft.",[16,196,197],{},"Der wesentliche Unterschied zu einer normalen Verkehrsspitze liegt in Absicht und Muster. Ein umsatzstarker Tag bringt Ihnen mehr echte Besucher, während ein DDoS-Angriff Ihnen Datenverkehr schickt, dessen einziger Zweck es ist, Ressourcen zu verbrauchen und echte Besucher zu verdrängen. Laut den DDoS-Bedrohungsberichten von Cloudflare ist das Angriffsvolumen von Jahr zu Jahr stark gestiegen, und die größten erfassten Angriffe werden inzwischen in Terabit pro Sekunde gemessen, weit jenseits dessen, was ein einzelner ungeschützter Server absorbieren kann.",[20,199,201],{"id":200},"wie-funktioniert-ein-ddos-angriff-eigentlich","Wie funktioniert ein DDoS-Angriff eigentlich?",[16,203,204],{},"Die meisten Angriffe fallen in drei grobe Kategorien, und es hilft zu wissen, welche welche ist, weil sie unterschiedlich abgewehrt werden.",[16,206,207],{},"Volumetrische Angriffe sind die Brute-Force-Variante: Sie sättigen Ihre verfügbare Bandbreite mit reiner Masse, etwa durch einen UDP-Flood, sodass nichts anderes mehr durchkommt. Protokollangriffe zielen auf die Art, wie Verbindungen aufgebaut werden, und erschöpfen Server- oder Firewall-Ressourcen mit etwa SYN-Floods, die Verbindungen öffnen und nie abschließen. Angriffe auf der Anwendungsebene sind die leisesten und oft am schwersten zu erkennen: Sie imitieren echtes Nutzerverhalten und senden Anfragen, die legitim wirken, aber auf die teuersten Teile Ihrer Website abzielen, etwa eine Such- oder Login-Funktion, bis die Anwendung zusammenbricht.",[16,209,210],{},"Was alle drei gemeinsam haben, ist, dass sie eine Ressource überlasten. Die Abwehr ist in jedem Fall dieselbe: den bösartigen Datenverkehr zu erkennen und zu entfernen, bevor er die angegriffene Ressource erreicht.",[20,212,214],{"id":213},"was-kostet-ein-ddos-angriff-ein-unternehmen","Was kostet ein DDoS-Angriff ein Unternehmen?",[16,216,217],{},"Die offensichtlichen Kosten sind der Ausfall: Solange die Website unerreichbar ist, können Besucher nicht buchen, kaufen oder Kontakt aufnehmen, und bei einer Website im Gesundheitswesen oder einer Klinik kann das bedeuten, dass Patienten keine Versorgungsinformationen oder Terminformulare erreichen. Branchenschätzungen beziffern die Kosten ungeplanter Website-Ausfälle häufig auf mehrere Tausend Euro pro Stunde für ein Unternehmen mit Online-Transaktionen, wobei die tatsächliche Zahl vollständig davon abhängt, was Ihre Website für Sie leistet.",[16,219,220],{},"Auch die weniger sichtbaren Kosten fallen ins Gewicht. Da ist der Reputationsschaden einer sichtbar ausgefallenen Website, die Personalzeit, die im Krisenmanagement gebunden wird, und in manchen Fällen ein DDoS-Angriff, der als Ablenkungsmanöver für einen zweiten Einbruchsversuch genutzt wird. Für eine regulierte oder patientenorientierte Organisation wirft ein Ausfall zudem Fragen zu Verfügbarkeit und Kontinuität auf, die über entgangenen Umsatz hinausgehen.",[20,222,224],{"id":223},"wie-hält-ddos-mitigation-eine-website-online","Wie hält DDoS-Mitigation eine Website online?",[16,226,227],{},"Wirksame Mitigation setzt eine Filterschicht zwischen das Internet und Ihren Server, sodass der Datenverkehr geprüft wird, bevor er Sie überhaupt erreicht. Legitime Besucher kommen durch, während Datenverkehr, der Angriffsmustern entspricht, am Rand des Netzwerks absorbiert oder verworfen wird, verteilt über eine Infrastruktur mit weit mehr Kapazität als ein einzelner Origin-Server.",[16,229,230],{},"Das funktioniert am besten als dauerhaft aktive Schicht statt als etwas, das man mitten im Angriff einschaltet, denn die ersten Minuten eines Angriffs sind die Minuten, in denen der Schaden entsteht. Ein Mitigationsdienst sieht den Datenverkehr zuerst, erkennt die Merkmale der oben genannten Angriffstypen und skaliert, um Volumen zu absorbieren, das Ihre eigene Hardware überfordern würde. Bei EuroraCloud läuft die DDoS-Mitigation über unsere dezentrale Infrastruktur in den Niederlanden, Frankreich und Deutschland, wodurch der Datenverkehr aus Gründen der Datensouveränität und Latenz innerhalb Europas bleibt und zugleich die Kapazität bereitsteht, um große Angriffe aufzufangen.",[20,232,101],{"id":100},[16,234,235],{},"Klären Sie zunächst, ob Sie derzeit überhaupt eine Mitigationsschicht haben, denn viele Websites sind nur durch die Standardeinstellungen ihres Hosting-Anbieters geschützt, die oft dürftig sind. Wenn ein Angriff heute Ihre Website offline nehmen würde, ist das die Lücke, die es zu schließen gilt, unabhängig davon, ob Sie je zuvor getroffen wurden, denn der ganze Sinn von Mitigation ist, dass sie bereits aktiv ist, wenn ein Angriff beginnt.",[16,237,238,239],{},"Wenn Sie sehen möchten, wo Ihre eigene Website steht, kann EuroraCloud Ihre aktuelle Einrichtung prüfen und Ihnen zeigen, was unsere Mitigation löst. ",[38,240,112],{"href":241,"rel":242},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=ddos",[42],[20,244,246],{"id":245},"fazit-was-sollten-sie-zum-ddos-schutz-mitnehmen","Fazit: Was sollten Sie zum DDoS-Schutz mitnehmen?",[16,248,249],{},"Ein DDoS-Angriff muss nichts durchbrechen, um Ihnen zu schaden. Er macht Ihre Website schlicht unerreichbar, und für ein Unternehmen, das auf seine Website angewiesen ist, um zu informieren, zu buchen oder zu verkaufen, ist eine Stunde offline ein realer Kostenfaktor. Die drei Angriffstypen funktionieren unterschiedlich, doch die Antwort auf alle drei ist dieselbe: eine Mitigationsschicht vor Ihrer Website, die bösartigen Datenverkehr herausfiltert, bevor er ankommt. Das Nützlichste, was Sie tun können, ist zu prüfen, ob diese Schicht heute bereits vorhanden ist, denn Mitigation schützt Sie nur, wenn sie aktiv ist, bevor ein Angriff beginnt, nicht danach.",{"title":121,"searchDepth":122,"depth":122,"links":251},[252,253,254,255,256,257],{"id":185,"depth":122,"text":186},{"id":200,"depth":122,"text":201},{"id":213,"depth":122,"text":214},{"id":223,"depth":122,"text":224},{"id":100,"depth":122,"text":101},{"id":245,"depth":122,"text":246},"Grundlagen","Ein DDoS-Angriff überflutet Ihre Website mit Datenverkehr, bis echte Besucher sie nicht mehr erreichen. So funktionieren diese Angriffe, was ein Ausfall wirklich kostet und wie Mitigation eine Website online hält.",[261,263,265,267,269,272],{"question":186,"answer":262},"Ein DDoS-Angriff (Distributed Denial of Service) versucht, eine Website unerreichbar zu machen, indem er sie mit Datenverkehr aus vielen Quellen gleichzeitig überflutet, oft Tausenden kompromittierten Geräten, die als Botnet agieren. Der Datenverkehr ist darauf ausgelegt, eine endliche Ressource zu erschöpfen, etwa die Verbindungen des Servers, seine Verarbeitungskapazität oder die Netzwerkbandbreite, sodass echte Besucher nicht mehr durchkommen.",{"question":201,"answer":264},"Angriffe fallen in drei grobe Kategorien. Volumetrische Angriffe sättigen die verfügbare Bandbreite mit reiner Masse. Protokollangriffe erschöpfen Server- oder Firewall-Ressourcen, indem sie den Verbindungsaufbau missbrauchen, etwa mit SYN-Floods. Angriffe auf der Anwendungsebene imitieren echtes Nutzerverhalten und zielen auf teure Funktionen wie Suche oder Login, bis die Anwendung zusammenbricht. Alle drei überlasten eine Ressource, und die Abwehr besteht jeweils darin, den bösartigen Datenverkehr zu entfernen, bevor er das Ziel erreicht.",{"question":214,"answer":266},"Die direkten Kosten sind der Ausfall: Solange die Website unerreichbar ist, können Besucher nicht buchen, kaufen oder Kontakt aufnehmen. Schätzungen beziffern ungeplante Website-Ausfälle häufig auf mehrere Tausend Euro pro Stunde für ein Unternehmen mit Transaktionen, wobei die tatsächliche Zahl davon abhängt, was die Website leistet. Indirekte Kosten sind Reputationsschaden, Personalzeit für das Krisenmanagement und das Risiko, dass ein DDoS-Angriff als Ablenkung für einen zweiten Einbruch dient.",{"question":224,"answer":268},"Mitigation setzt eine Filterschicht zwischen das Internet und Ihren Server und prüft den Datenverkehr, bevor er Sie erreicht. Legitime Besucher kommen durch, während Datenverkehr, der Angriffsmustern entspricht, am Rand absorbiert oder verworfen wird, verteilt über eine Infrastruktur mit weit mehr Kapazität als ein einzelner Server. Es funktioniert am besten als dauerhaft aktive Schicht statt als etwas, das man mitten im Angriff einschaltet, denn die ersten Minuten sind die, in denen der Schaden entsteht.",{"question":270,"answer":271},"Was sollten Sie als Nächstes tun, um eine Website vor DDoS zu schützen?","Prüfen Sie zunächst, ob Sie überhaupt eine Mitigationsschicht haben, denn viele Websites verlassen sich nur auf die dürftigen Standardeinstellungen ihres Hosting-Anbieters. Wenn ein Angriff heute Ihre Website offline nehmen würde, ist das die zu schließende Lücke, unabhängig davon, ob Sie zuvor getroffen wurden, denn Mitigation hilft nur, wenn sie bereits aktiv ist, wenn ein Angriff beginnt.",{"question":273,"answer":274},"Was sollten Sie zum DDoS-Schutz mitnehmen?","Ein DDoS-Angriff muss nichts durchbrechen, um Ihnen zu schaden; er macht Ihre Website schlicht unerreichbar, was für jedes Unternehmen, das auf seine Website angewiesen ist, ein realer Kostenfaktor ist. Die drei Angriffstypen funktionieren unterschiedlich, doch die Antwort auf alle drei ist eine Mitigationsschicht vor der Website, die bösartigen Datenverkehr herausfiltert, bevor er ankommt. Das Nützlichste ist zu prüfen, ob diese Schicht heute bereits aktiv ist, denn Mitigation schützt nur, wenn sie vor Beginn eines Angriffs läuft.",{},"\u002Fblog\u002Fde\u002Fwhat-is-a-ddos-attack","7 Minuten",{"title":174,"description":259},"what-is-a-ddos-attack","blog\u002Fde\u002Fwhat-is-a-ddos-attack",[282,283,284,285],"DDoS","Sicherheit","Web-Infrastruktur","Verfügbarkeit","0RuEdiFFMTEZBQwMmEtFMZLmNpvydscZIjN9R9abPY0",{"id":288,"title":289,"author":7,"body":290,"category":132,"date":133,"description":372,"extension":135,"faq":373,"meta":392,"navigation":159,"path":393,"readingTime":277,"seo":394,"slug":395,"stem":396,"tags":397,"__hash__":400},"blog\u002Fblog\u002Fde\u002Fwhat-is-cross-origin-opener-policy.md","Was ist der Cross-Origin-Opener-Policy Header und warum ist er wichtig?",{"type":9,"value":291,"toc":363},[292,295,298,302,305,308,312,315,318,320,323,326,330,333,336,338,341,344,346,349,356,360],[12,293,289],{"id":294},"was-ist-der-cross-origin-opener-policy-header-und-warum-ist-er-wichtig",[16,296,297],{},"Der Cross-Origin-Opener-Policy Header, meist als COOP geschrieben, ist ein Response-Header, der steuert, ob Ihre Seite eine Fensterbeziehung mit Seiten anderer Origins teilt. Auf same-origin gesetzt, isoliert er Ihr Dokument in einer eigenen Browsing Context Group, sodass eine Seite einer anderen Origin, die die Ihre öffnet oder die Sie öffnen, keine skriptfähige Referenz zurück auf Ihr Fenster halten kann. Das schließt eine Klasse von Cross-Origin-Angriffen, die als XS-Leaks und Side-Channel-Angriffe bekannt sind, und es ist zugleich die Einstellung, die bestimmte leistungsstarke Browserfunktionen freischaltet.",[20,299,301],{"id":300},"warum-gibt-es-den-cross-origin-opener-policy-header","Warum gibt es den Cross-Origin-Opener-Policy Header?",[16,303,304],{},"COOP existiert, weil das Öffnen eines Fensters eine Verbindung schafft, die missbraucht werden kann. Wenn eine Seite eine andere mit window.open() öffnet, oder eine Seite die Ihre öffnet, kann der Browser über die Eigenschaft window.opener eine Referenz zwischen den beiden Fenstern behalten. Stammen diese beiden Seiten von unterschiedlichen Origins, wird diese Referenz zu einem Weg, über den eine Cross-Origin-Seite die Ihre ausspähen kann.",[16,306,307],{},"Die Angriffe, die dies ermöglicht, sind subtil. Sie stehlen Ihre Daten nicht direkt, sondern leiten sie über Side Channels, Timing und gemeinsam genutzten Browserzustand ab, in einer Familie von Techniken, die die Sicherheitsgemeinschaft XS-Leaks nennt. Laut der Dokumentation von Mozilla wurde COOP genau dafür eingeführt, dass eine Website sicherstellen kann, dass ihr Top-Level-Dokument keine Browsing Context Group mit Cross-Origin-Dokumenten teilt, und genau das trennt diese Referenz und schließt den Weg.",[20,309,311],{"id":310},"was-leistet-der-cross-origin-opener-policy-header-eigentlich","Was leistet der Cross-Origin-Opener-Policy Header eigentlich?",[16,313,314],{},"COOP entscheidet, ob Ihr Dokument und die Seiten, mit denen es interagiert, zur selben Browsing Context Group gehören, dem internen Browserbegriff, der bestimmt, ob zwei Fenster einander skripten können. Wenn Sie ihn streng setzen, kommt Ihr Fenster in eine eigene Gruppe, und jedes Cross-Origin-Fenster verliert seine Referenz auf das Ihre.",[16,316,317],{},"Der Header kennt eine kleine Wertemenge. Der Standardwert, unsafe-none, wendet keine Isolierung an und lässt Ihr Dokument eine Browsing Context Group mit Cross-Origin-Seiten teilen. Der strenge Wert, same-origin, isoliert Ihr Dokument so, dass nur Same-Origin-Seiten, die selbst ebenfalls same-origin setzen, in derselben Gruppe bleiben können. Ein Zwischenwert, same-origin-allow-popups, erhält diese Isolierung, lässt aber Popups, die Sie selbst öffnen, normal funktionieren, was die praktische Wahl für Websites ist, die auf Popup-Abläufe wie Bezahlung oder Single Sign-on angewiesen sind. Wird ein Cross-Origin-Fenster unter same-origin geöffnet, wird sein window.opener zu null, sodass die Referenz schlicht nicht existiert.",[20,319,68],{"id":67},[16,321,322],{},"Ohne COOP gilt der Standard unsafe-none, was bedeutet, dass es keine Isolierung gibt und die Fensterreferenz offen bleibt. Eine Cross-Origin-Seite, die die Ihre öffnet, oder die Sie öffnen, kann einen Zugriff auf Ihr Fenster behalten und ihn als Ansatzpunkt für die oben beschriebenen Side-Channel-Techniken nutzen.",[16,324,325],{},"Dies ist eine leise Lücke, keine laute. Nichts auf Ihrer Website wirkt kaputt, und die meisten Besucher werden sie nie auslösen, und genau deshalb bleibt sie oft unbehandelt. Doch für eine Website, die etwas Sensibles verarbeitet, einen Login, ein Patientenportal, einen Bezahlschritt, ist das Offenlassen der Fensterbeziehung eine vermeidbare Angriffsfläche, und es ist eine, die Sicherheitsscanner und Audits zunehmend als fehlenden Header kennzeichnen.",[20,327,329],{"id":328},"wie-implementieren-sie-den-cross-origin-opener-policy-header","Wie implementieren Sie den Cross-Origin-Opener-Policy Header?",[16,331,332],{},"Sie setzen COOP als einen einzigen HTTP-Response-Header. Für die meisten Websites ist der richtige Startwert Cross-Origin-Opener-Policy: same-origin-allow-popups, der Ihnen Isolierung gibt und zugleich Popup-Abläufe erhält; eine Website ohne solche Abhängigkeiten kann zum strengeren same-origin wechseln. Er kann am Webserver, in der Anwendungsebene oder am Rand in einem CDN oder einer Sicherheitsschicht vor der Website hinzugefügt werden.",[16,334,335],{},"Die einzige nachdrückliche Empfehlung lautet: testen, bevor Sie erzwingen. COOP unterstützt einen Report-only-Modus, gesendet als Cross-Origin-Opener-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um Ihnen mitzuteilen, was die Richtlinie brechen würde, ohne dass tatsächlich etwas bricht. Zuerst Report-only zu betreiben, auf Popup- oder Fensterabläufe zu achten, die betroffen wären, und erst dann auf den erzwungenen Header umzuschalten, ist der sichere Weg, besonders bei einer Website mit Integrationen Dritter, die Sie nicht selbst gebaut haben.",[20,337,91],{"id":90},[16,339,340],{},"Für die meisten Websites nichts Sichtbares. Gewöhnliche Seitenaufrufe, Navigation und Same-Origin-Verhalten bleiben unberührt, und die Isolierung geschieht unsichtbar auf Browserebene. Der Gewinn ist, dass Cross-Origin-Fenster keine Referenz auf das Ihre mehr halten können, was die Angriffsfläche beseitigt, ohne die Nutzererfahrung zu berühren.",[16,342,343],{},"Zu prüfen ist jeder Ablauf, der bewusst eine andere Origin öffnet oder von ihr geöffnet wird. Ein Zahlungsanbieter, ein Identity Provider oder ein eingebettetes Tool, das über Fensterreferenzen kommuniziert, kann von einem strengen Same-Origin-Wert betroffen sein, und genau deshalb gibt es same-origin-allow-popups und deshalb ist das Testen im Report-only-Modus wichtig. Es gibt auch einen erwähnenswerten Vorteil: same-origin gemeinsam mit dem verwandten Cross-Origin-Embedder-Policy Header zu setzen, versetzt Ihr Dokument in einen Cross-Origin-Isolated-Zustand, den manche leistungsstarke Browserfunktionen voraussetzen, etwa SharedArrayBuffer und hochauflösende Timer.",[20,345,101],{"id":100},[16,347,348],{},"Prüfen Sie zunächst, ob Ihre Website überhaupt einen Cross-Origin-Opener-Policy Header sendet, denn der Standard ohne Header bedeutet keine Isolierung. Fehlt er, ist der risikoarme Weg, ihn im Report-only-Modus hinzuzufügen, zu bestätigen, dass in Ihren Popup- oder Drittanbieter-Abläufen nichts bricht, und dann same-origin-allow-popups als sinnvollen Standard zu erzwingen, oder same-origin, wenn Ihre Website keine Popup-Abhängigkeiten hat.",[16,350,351,352],{},"Wenn Sie dies über Ihre gesamte Website hinweg korrekt prüfen und konfigurieren lassen möchten statt Stück für Stück, kann EuroraCloud Ihre aktuellen Security Header überprüfen und Ihnen zeigen, was unsere Plattform löst. ",[38,353,112],{"href":354,"rel":355},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[42],[20,357,359],{"id":358},"fazit-was-sollten-sie-zum-cross-origin-opener-policy-header-mitnehmen","Fazit: Was sollten Sie zum Cross-Origin-Opener-Policy Header mitnehmen?",[16,361,362],{},"COOP ist ein leiser, aber lohnender Header: Er isoliert Ihr Browserfenster von Cross-Origin-Seiten und schließt eine Klasse von Side-Channel- und Popup-Angriffen, die kein sichtbares Zeichen hinterlassen, bis ein Scanner oder ein Angreifer sie findet. Für die meisten Websites ist der sichere Weg, im Report-only-Modus zu testen und dann same-origin-allow-popups zu erzwingen, was das Fenster schützt und zugleich legitime Popup-Abläufe erhält. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, ist der Standard gar keine Isolierung.",{"title":121,"searchDepth":122,"depth":122,"links":364},[365,366,367,368,369,370,371],{"id":300,"depth":122,"text":301},{"id":310,"depth":122,"text":311},{"id":67,"depth":122,"text":68},{"id":328,"depth":122,"text":329},{"id":90,"depth":122,"text":91},{"id":100,"depth":122,"text":101},{"id":358,"depth":122,"text":359},"Der Cross-Origin-Opener-Policy Header ermöglicht es einer Seite, ihr Browserfenster von Cross-Origin-Seiten zu isolieren, die sie öffnen oder von ihr geöffnet werden, und schließt so eine Klasse von Side-Channel- und Popup-Angriffen. Das leistet der Header, so setzen Sie ihn, und das ändert sich dadurch.",[374,376,378,381,383,386,389],{"question":301,"answer":375},"COOP existiert, weil das Öffnen eines Fensters eine skriptfähige Verbindung schafft, die missbraucht werden kann. Wenn eine Seite eine andere öffnet, kann der Browser über window.opener eine Referenz zwischen den beiden Fenstern behalten, und stammen die Seiten von unterschiedlichen Origins, wird diese Referenz zu einem Weg, über den eine Cross-Origin-Seite die Ihre über Side Channels und Timing ausspähen kann, eine Familie von Techniken, die als XS-Leaks bekannt ist. COOP lässt eine Website sicherstellen, dass ihr Top-Level-Dokument keine Browsing Context Group mit Cross-Origin-Dokumenten teilt, was diese Referenz trennt.",{"question":311,"answer":377},"COOP entscheidet, ob Ihr Dokument und die Seiten, mit denen es interagiert, zur selben Browsing Context Group gehören, dem internen Browserbegriff, der bestimmt, ob zwei Fenster einander skripten können. Streng gesetzt kommt Ihr Fenster in eine eigene Gruppe und Cross-Origin-Fenster verlieren ihre Referenz auf das Ihre. Die Werte sind unsafe-none (Standard, keine Isolierung), same-origin (strenge Isolierung) und same-origin-allow-popups (Isolierung, die von Ihnen geöffnete Popups zulässt). Unter same-origin wird der window.opener eines Cross-Origin-Fensters zu null.",{"question":379,"answer":380},"Was passiert, wenn Sie den Cross-Origin-Opener-Policy Header nicht setzen?","Ohne COOP gilt der Standard unsafe-none, was bedeutet, dass es keine Isolierung gibt und die Fensterreferenz offen bleibt. Eine Cross-Origin-Seite, die die Ihre öffnet, oder die Sie öffnen, kann einen Zugriff auf Ihr Fenster behalten und ihn als Ansatzpunkt für Side-Channel-Angriffe nutzen. Nichts wirkt kaputt, und deshalb bleibt es unbehandelt, doch für eine Website mit einem Login, Patientenportal oder Bezahlschritt ist es eine vermeidbare Angriffsfläche, die Scanner zunehmend kennzeichnen.",{"question":329,"answer":382},"Setzen Sie COOP als einen einzigen HTTP-Response-Header, am Webserver, in der Anwendungsebene oder am Rand. Für die meisten Websites ist der richtige Startwert same-origin-allow-popups, der Isolierung gibt und Popup-Abläufe erhält; eine Website ohne Popup-Abhängigkeiten kann das strengere same-origin verwenden. Testen Sie vor dem Erzwingen mit dem Report-only-Modus, gesendet als Cross-Origin-Opener-Policy-Report-Only, der meldet, was die Richtlinie brechen würde, ohne sie zu brechen.",{"question":384,"answer":385},"Was ändert sich auf Ihrer Website, sobald der Cross-Origin-Opener-Policy Header aktiv ist?","Für die meisten Websites ändert sich nichts Sichtbares; gewöhnliche Seitenaufrufe und Same-Origin-Verhalten bleiben unberührt und die Isolierung geschieht auf Browserebene. Zu prüfen ist jeder Ablauf, der bewusst eine andere Origin öffnet oder von ihr geöffnet wird, etwa ein Zahlungs- oder Identity-Provider, weshalb es same-origin-allow-popups gibt und das Testen im Report-only-Modus wichtig ist. same-origin gemeinsam mit Cross-Origin-Embedder-Policy zu setzen, aktiviert zudem einen Cross-Origin-Isolated-Zustand, den manche leistungsstarke Funktionen wie SharedArrayBuffer voraussetzen.",{"question":387,"answer":388},"Was sollten Sie als Nächstes zum Cross-Origin-Opener-Policy Header tun?","Prüfen Sie, ob Ihre Website überhaupt einen Cross-Origin-Opener-Policy Header sendet, denn kein Header bedeutet keine Isolierung. Fehlt er, fügen Sie ihn im Report-only-Modus hinzu, bestätigen Sie, dass in Ihren Popup- oder Drittanbieter-Abläufen nichts bricht, und erzwingen Sie dann same-origin-allow-popups als sinnvollen Standard, oder same-origin, wenn Ihre Website keine Popup-Abhängigkeiten hat.",{"question":390,"answer":391},"Was sollten Sie zum Cross-Origin-Opener-Policy Header mitnehmen?","COOP ist ein leiser, aber lohnender Header, der Ihr Browserfenster von Cross-Origin-Seiten isoliert und eine Klasse von Side-Channel- und Popup-Angriffen schließt, die kein sichtbares Zeichen hinterlassen. Für die meisten Websites ist der sichere Weg, im Report-only-Modus zu testen und dann same-origin-allow-popups zu erzwingen, was das Fenster schützt und legitime Popup-Abläufe erhält. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, ist der Standard gar keine Isolierung.",{},"\u002Fblog\u002Fde\u002Fwhat-is-cross-origin-opener-policy",{"title":289,"description":372},"what-is-cross-origin-opener-policy","blog\u002Fde\u002Fwhat-is-cross-origin-opener-policy",[398,132,167,399],"Cross-Origin-Opener-Policy","Browser-Isolierung","dIQHUjFaEJBccxaQDY70KD3e_dwisCj55HESIIkenGg",{"id":402,"title":403,"author":7,"body":404,"category":1022,"date":1023,"description":1024,"extension":135,"faq":1022,"meta":1025,"navigation":159,"path":1026,"readingTime":1022,"seo":1027,"slug":1028,"stem":1029,"tags":1030,"__hash__":1034},"blog\u002Fblog\u002Fde\u002Fcore-web-vitals-cdn.md","Core Web Vitals: Wie ein CDN Ihrer Website zu Besseren Werten Verhilft",{"type":9,"value":405,"toc":1000},[406,413,416,419,422,426,429,434,441,447,452,468,472,475,481,487,492,506,510,516,522,527,541,545,548,552,557,560,563,568,571,597,602,605,609,612,617,620,625,628,639,642,647,650,661,665,670,673,678,681,695,700,703,707,710,714,719,728,731,736,742,745,749,752,779,783,786,806,810,813,834,838,841,846,857,862,873,876,880,885,888,893,896,901,904,909,912,916,919,924,927,932,946,951,954,959,962,966,969,972,984,986,996],[16,407,408,412],{},[409,410,411],"strong",{},"Schlüsselwörter:"," Core Web Vitals, CDN Performance, LCP Optimierung, FID Verbesserung, CLS Behebung, Website-Geschwindigkeit, Google Ranking-Faktoren, Seitenerfahrung, Web Performance Optimierung, Europäisches CDN",[414,415],"hr",{},[16,417,418],{},"Im Jahr 2021 führte Google Core Web Vitals als offizielle Ranking-Faktoren ein und veränderte damit grundlegend, wie Website-Betreiber über Performance nachdenken. Diese Metriken—Largest Contentful Paint (LCP), First Input Delay (FID) und Cumulative Layout Shift (CLS)—messen die echte Benutzererfahrung und beeinflussen direkt Ihre Sichtbarkeit in der Suche. Seit 2024 hat Google FID durch Interaction to Next Paint (INP) ersetzt, wodurch Interaktivität noch wichtiger geworden ist.",[16,420,421],{},"Wenn Ihre Website mit Core Web Vitals kämpft, sind Sie nicht allein. Aktuellen Daten zufolge erreichen etwa 40% der Websites noch immer nicht die Schwellenwerte von Google. Die gute Nachricht? Ein richtig konfiguriertes Content Delivery Network (CDN) kann alle drei Metriken dramatisch verbessern. In diesem umfassenden Leitfaden zeigen wir genau, wie das funktioniert.",[20,423,425],{"id":424},"core-web-vitals-in-2026-verstehen","Core Web Vitals in 2026 Verstehen",[16,427,428],{},"Bevor wir in die CDN-Optimierung eintauchen, verstehen wir zunächst, was jede Metrik misst und warum sie wichtig ist.",[430,431,433],"h3",{"id":432},"largest-contentful-paint-lcp","Largest Contentful Paint (LCP)",[16,435,436,437,440],{},"LCP misst die Ladeleistung—genauer gesagt, wie lange es dauert, bis das größte sichtbare Content-Element gerendert wird. Das kann ein Hero-Bild, ein Video-Thumbnail oder ein großer Textblock sein. Google betrachtet einen guten LCP als ",[409,438,439],{},"2,5 Sekunden oder weniger",".",[16,442,443,446],{},[409,444,445],{},"Warum LCP wichtig ist:"," Nutzer nehmen eine Seite als \"geladen\" wahr, wenn sie den Hauptinhalt sehen können. Ein langsamer LCP bedeutet, dass Besucher auf einen leeren oder teilweise geladenen Bildschirm starren, was die Absprungrate erhöht.",[16,448,449],{},[409,450,451],{},"Häufige LCP-Probleme:",[453,454,455,459,462,465],"ul",{},[456,457,458],"li",{},"Langsame Server-Antwortzeiten",[456,460,461],{},"Render-blockierendes JavaScript und CSS",[456,463,464],{},"Große, nicht optimierte Bilder",[456,466,467],{},"Verzögerungen durch Client-Side Rendering",[430,469,471],{"id":470},"interaction-to-next-paint-inp","Interaction to Next Paint (INP)",[16,473,474],{},"INP ersetzte First Input Delay im März 2024 und misst die gesamte Reaktionsfähigkeit während des gesamten Seitenlebenszyklus. Während FID nur die Verzögerung der ersten Interaktion maß, berücksichtigt INP alle Interaktionen—Klicks, Tippen und Tastatureingaben—und meldet die schlechteste (mit statistischer Glättung).",[16,476,477,478,440],{},"Google betrachtet einen guten INP als ",[409,479,480],{},"200 Millisekunden oder weniger",[16,482,483,486],{},[409,484,485],{},"Warum INP wichtig ist:"," Nutzer erwarten sofortiges Feedback, wenn sie mit Ihrer Website interagieren. Ein verzögerter Button oder ein nicht reagierendes Formular fühlt sich kaputt an, selbst wenn die Seite schnell geladen hat.",[16,488,489],{},[409,490,491],{},"Häufige INP-Probleme:",[453,493,494,497,500,503],{},[456,495,496],{},"Schwere JavaScript-Ausführung, die den Main Thread blockiert",[456,498,499],{},"Third-Party-Scripts, die um Ressourcen konkurrieren",[456,501,502],{},"Ineffiziente Event-Handler",[456,504,505],{},"Komplexe DOM-Operationen während Interaktionen",[430,507,509],{"id":508},"cumulative-layout-shift-cls","Cumulative Layout Shift (CLS)",[16,511,512,513,440],{},"CLS misst die visuelle Stabilität—wie stark sich der Seiteninhalt während des Ladens bewegt. Jedes Mal, wenn ein Element unerwartet seine Position ändert, trägt es zu Ihrem CLS-Score bei. Google betrachtet einen guten CLS als ",[409,514,515],{},"0,1 oder weniger",[16,517,518,521],{},[409,519,520],{},"Warum CLS wichtig ist:"," Unerwartete Layout-Verschiebungen sind frustrierend. Sie wollen gerade einen Link anklicken, und plötzlich lädt darüber eine Anzeige, die alles nach unten schiebt. Jetzt haben Sie auf das Falsche geklickt. CLS erfasst diese Frustration quantitativ.",[16,523,524],{},[409,525,526],{},"Häufige CLS-Probleme:",[453,528,529,532,535,538],{},[456,530,531],{},"Bilder und Einbettungen ohne definierte Dimensionen",[456,533,534],{},"Dynamisch eingefügter Inhalt",[456,536,537],{},"Webfonts, die Text-Reflow verursachen",[456,539,540],{},"Anzeigen und iframes, die spät laden",[20,542,544],{"id":543},"wie-ein-cdn-jede-core-web-vital-verbessert","Wie ein CDN Jede Core Web Vital Verbessert",[16,546,547],{},"Ein CDN geht nicht nur um Geschwindigkeit—es ist ein Performance-Multiplikator, der mehrere Schmerzpunkte gleichzeitig adressiert. So hilft es bei jeder Metrik.",[430,549,551],{"id":550},"cdn-auswirkung-auf-lcp","CDN-Auswirkung auf LCP",[16,553,554],{},[409,555,556],{},"Reduzierte Time to First Byte (TTFB)",[16,558,559],{},"Der wichtigste Faktor bei LCP ist oft TTFB—wie lange der Browser wartet, bevor er das erste Byte HTML erhält. Wenn Ihr Server in Frankfurt steht und Ihr Besucher in Madrid ist, muss jede Anfrage Hunderte von Kilometern zurücklegen. Ein CDN mit Edge-Servern in ganz Europa eliminiert diese Latenz.",[16,561,562],{},"Mit EuroraCloud's 45+ europäischen Points of Presence wird Ihr Content von einem Standort geliefert, der typischerweise innerhalb von 50ms von Ihren Besuchern entfernt ist. Allein das kann 200-500ms von Ihrem LCP abziehen.",[16,564,565],{},[409,566,567],{},"Optimierte Bildauslieferung",[16,569,570],{},"Bilder sind das LCP-Element auf den meisten Seiten. Ein CDN kann:",[453,572,573,579,585,591],{},[456,574,575,578],{},[409,576,577],{},"Moderne Formate liefern:"," Bilder automatisch in WebP oder AVIF konvertieren, wodurch Dateigrößen um 30-50% reduziert werden",[456,580,581,584],{},[409,582,583],{},"Responsive Sizing:"," Passend dimensionierte Bilder basierend auf dem Device Viewport liefern",[456,586,587,590],{},[409,588,589],{},"Lazy Loading Optimierung:"," Sicherstellen, dass Above-the-Fold-Bilder sofort laden, während andere verzögert werden",[456,592,593,596],{},[409,594,595],{},"Kompression:"," Optimale Kompression ohne sichtbaren Qualitätsverlust anwenden",[16,598,599],{},[409,600,601],{},"Caching eliminiert Origin-Anfragen",[16,603,604],{},"Wenn Content am Edge gecacht ist, erhalten Besucher ihn direkt ohne jegliche Anfrage an Ihren Origin-Server. Das ist dramatisch schneller als selbst die am besten optimierte Origin-Antwort.",[430,606,608],{"id":607},"cdn-auswirkung-auf-inp","CDN-Auswirkung auf INP",[16,610,611],{},"Obwohl INP primär durch Client-Side JavaScript beeinflusst wird, trägt ein CDN auf mehrere wichtige Arten bei:",[16,613,614],{},[409,615,616],{},"Schnellere Script-Auslieferung",[16,618,619],{},"Ihre JavaScript-Dateien erreichen Besucher schneller, wenn sie von Edge-Standorten geliefert werden. Das bedeutet, Ihre interaktiven Elemente werden früher funktionsfähig.",[16,621,622],{},[409,623,624],{},"HTTP\u002F3 und Verbindungsoptimierung",[16,626,627],{},"Moderne CDNs unterstützen HTTP\u002F3 (QUIC), was bietet:",[453,629,630,633,636],{},[456,631,632],{},"Zero Round-Trip Verbindungsaufbau",[456,634,635],{},"Verbessertes Paketverlustwiederherstelling",[456,637,638],{},"Gemultiplexte Streams ohne Head-of-Line Blocking",[16,640,641],{},"Diese Optimierungen reduzieren den Overhead beim Laden mehrerer Ressourcen und lassen mehr Main-Thread-Zeit für die Behandlung von Interaktionen.",[16,643,644],{},[409,645,646],{},"Edge Computing für dynamische Features",[16,648,649],{},"Fortgeschrittene CDNs bieten Edge-Computing-Fähigkeiten, mit denen Sie Logik am Netzwerkrand ausführen können. Das kann Arbeit vom Client auslagern:",[453,651,652,655,658],{},[456,653,654],{},"A\u002FB-Test-Entscheidungen am Edge statt Client-Side",[456,656,657],{},"Personalisierung ohne JavaScript",[456,659,660],{},"Formularvalidierung und -verarbeitung",[430,662,664],{"id":663},"cdn-auswirkung-auf-cls","CDN-Auswirkung auf CLS",[16,666,667],{},[409,668,669],{},"Platzhalter und Dimensionsdurchsetzung",[16,671,672],{},"Ein CDN mit Bildoptimierung kann automatisch width- und height-Attribute zu Bildern hinzufügen, um Layout-Verschiebungen beim Laden zu verhindern.",[16,674,675],{},[409,676,677],{},"Font-Optimierung",[16,679,680],{},"Webfonts sind ein großer CLS-Übeltäter. Wenn eine benutzerdefinierte Schriftart lädt, verursacht sie oft Text-Reflow (bekannt als FOUT—Flash of Unstyled Text). CDN-Optimierung umfasst:",[453,682,683,686,689,692],{},[456,684,685],{},"Preloading kritischer Fonts",[456,687,688],{},"Font Subsetting zur Reduzierung der Dateigrößen",[456,690,691],{},"font-display: swap Behandlung",[456,693,694],{},"Fonts von Edge-Standorten für schnelleres Laden liefern",[16,696,697],{},[409,698,699],{},"Konsistentes Third-Party Loading",[16,701,702],{},"Obwohl Sie nicht kontrollieren können, wie Third-Party-Scripts sich verhalten, sorgt das Ausliefern über Ihr CDN (wo möglich) für konsistenteres Timing, was unerwartete Verschiebungen reduziert.",[20,704,706],{"id":705},"praktische-cdn-konfiguration-für-core-web-vitals","Praktische CDN-Konfiguration für Core Web Vitals",[16,708,709],{},"Werden wir konkret, wie Sie Ihr CDN für optimale Core Web Vitals konfigurieren.",[430,711,713],{"id":712},"caching-strategie","Caching-Strategie",[16,715,716],{},[409,717,718],{},"Statische Assets (Bilder, CSS, JS):",[720,721,726],"pre",{"className":722,"code":724,"language":725},[723],"language-text","Cache-Control: public, max-age=31536000, immutable\n","text",[45,727,724],{"__ignoreMap":121},[16,729,730],{},"Verwenden Sie lange Cache-Dauern mit Cache-Busting-Dateinamen für Versionierung.",[16,732,733],{},[409,734,735],{},"HTML-Dokumente:",[720,737,740],{"className":738,"code":739,"language":725},[723],"Cache-Control: public, max-age=300, stale-while-revalidate=86400\n",[45,741,739],{"__ignoreMap":121},[16,743,744],{},"Kurze TTL mit stale-while-revalidate sorgt für frischen Content und vermeidet Origin-Verzögerungen.",[430,746,748],{"id":747},"bildoptimierungs-einstellungen","Bildoptimierungs-Einstellungen",[16,750,751],{},"Aktivieren Sie diese Features, wenn Ihr CDN sie unterstützt:",[753,754,755,761,767,773],"ol",{},[456,756,757,760],{},[409,758,759],{},"Automatische WebP\u002FAVIF-Konvertierung"," - Moderne Formate an unterstützte Browser liefern",[456,762,763,766],{},[409,764,765],{},"Responsive Bilder"," - Passende Größen via Client Hints liefern",[456,768,769,772],{},[409,770,771],{},"Lazy Loading Injection"," - loading=\"lazy\" zu Below-Fold-Bildern hinzufügen",[456,774,775,778],{},[409,776,777],{},"Qualitätsoptimierung"," - Perzeptuelle Qualitätsmetriken (wie SSIM) statt fester Kompression verwenden",[430,780,782],{"id":781},"preloading-kritischer-ressourcen","Preloading Kritischer Ressourcen",[16,784,785],{},"Verwenden Sie HTTP\u002F2 Server Push oder 103 Early Hints zum Preloading kritischer Ressourcen:",[720,787,791],{"className":788,"code":789,"language":790,"meta":121,"style":121},"language-http shiki shiki-themes github-light github-dark","Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\nLink: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n","http",[45,792,793,801],{"__ignoreMap":121},[794,795,798],"span",{"class":796,"line":797},"line",1,[794,799,800],{},"Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\n",[794,802,803],{"class":796,"line":122},[794,804,805],{},"Link: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n",[430,807,809],{"id":808},"sicherheits-header-ohne-performance-kosten","Sicherheits-Header Ohne Performance-Kosten",[16,811,812],{},"CDNs können Sicherheits-Header am Edge hinzufügen, ohne Ihren Origin zu belasten:",[720,814,816],{"className":788,"code":815,"language":790,"meta":121,"style":121},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\n",[45,817,818,823,828],{"__ignoreMap":121},[794,819,820],{"class":796,"line":797},[794,821,822],{},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\n",[794,824,825],{"class":796,"line":122},[794,826,827],{},"X-Content-Type-Options: nosniff\n",[794,829,831],{"class":796,"line":830},3,[794,832,833],{},"Referrer-Policy: strict-origin-when-cross-origin\n",[20,835,837],{"id":836},"die-auswirkungen-messen","Die Auswirkungen Messen",[16,839,840],{},"Nach der Implementierung von CDN-Optimierungen messen Sie Ihre Verbesserungen mit:",[16,842,843],{},[409,844,845],{},"Lab-Tools (synthetisches Testen):",[453,847,848,851,854],{},[456,849,850],{},"Google Lighthouse",[456,852,853],{},"WebPageTest",[456,855,856],{},"Chrome DevTools Performance Panel",[16,858,859],{},[409,860,861],{},"Felddaten (echte Nutzer):",[453,863,864,867,870],{},[456,865,866],{},"Google Search Console Core Web Vitals Bericht",[456,868,869],{},"Chrome User Experience Report (CrUX)",[456,871,872],{},"Real User Monitoring (RUM) Lösungen",[16,874,875],{},"Die CrUX-Daten sind das, was Google tatsächlich für das Ranking verwendet, also priorisieren Sie Felddaten gegenüber Lab-Messungen.",[20,877,879],{"id":878},"häufige-fehler-die-sie-vermeiden-sollten","Häufige Fehler, die Sie Vermeiden Sollten",[16,881,882],{},[409,883,884],{},"Dynamischen Content zu aggressiv cachen",[16,886,887],{},"HTML zu aggressiv zu cachen kann dazu führen, dass Nutzer veralteten Content sehen. Verwenden Sie angemessene TTLs und Cache-Busting für personalisierte Elemente.",[16,889,890],{},[409,891,892],{},"Mobile Nutzer vergessen",[16,894,895],{},"Mobile Netzwerke haben höhere Latenz und variablere Performance. Testen Sie speziell auf gedrosselten mobilen Verbindungen.",[16,897,898],{},[409,899,900],{},"Third Parties vergessen",[16,902,903],{},"Ihr CDN kann nur Ressourcen optimieren, die es ausliefert. Auditieren Sie Third-Party-Scripts und entfernen oder verzögern Sie nicht-essentielle.",[16,905,906],{},[409,907,908],{},"Nur Lab-Daten messen",[16,910,911],{},"Lab-Tests zeigen Potenzial, nicht Realität. Ihre echten Nutzer haben möglicherweise andere Geräte, Netzwerke und Verhaltensweisen.",[20,913,915],{"id":914},"warum-europäische-unternehmen-euroracloud-wählen","Warum Europäische Unternehmen EuroraCloud Wählen",[16,917,918],{},"Für europäische Websites ist der Datenstandort wichtig—sowohl für Compliance als auch für Performance. EuroraCloud bietet:",[16,920,921],{},[409,922,923],{},"45+ Europäische Edge-Standorte",[16,925,926],{},"Von Lissabon bis Helsinki, Stockholm bis Athen—Ihr Content wird nah bei Ihren europäischen Besuchern gecacht. Das übersetzt sich in konstant schnelle LCP-Zeiten auf dem gesamten Kontinent.",[16,928,929],{},[409,930,931],{},"Integrierte Performance-Features",[453,933,934,937,940,943],{},[456,935,936],{},"Automatische Bildoptimierung mit WebP\u002FAVIF-Unterstützung",[456,938,939],{},"HTTP\u002F3 standardmäßig aktiviert",[456,941,942],{},"Intelligentes Caching mit sofortiger Purge-Möglichkeit",[456,944,945],{},"Echtzeit-Performance-Analytics",[16,947,948],{},[409,949,950],{},"DSGVO-konforme Infrastruktur",[16,952,953],{},"Alle Verarbeitung findet innerhalb der EU statt. Keine Datentransfers in Drittländer, was Ihre Compliance-Pflichten vereinfacht.",[16,955,956],{},[409,957,958],{},"Einfache, Transparente Preise",[16,960,961],{},"Keine versteckten Gebühren für Features, die Standard sein sollten. Performance-Optimierung ist inklusive, kein Add-on.",[20,963,965],{"id":964},"fazit","Fazit",[16,967,968],{},"Core Web Vitals sind nicht nur Eitelkeitsmetriken—sie beeinflussen direkt Ihre Suchrankings und Benutzererfahrung. Ein CDN ist eines der effektivsten Tools, um alle drei Metriken gleichzeitig zu verbessern.",[16,970,971],{},"Durch die Reduzierung von Latenz, Optimierung von Assets und Bereitstellung moderner Auslieferungsprotokolle kann ein richtig konfiguriertes CDN Ihre Core Web Vitals Scores transformieren. Für europäische Unternehmen gewährleistet die Wahl eines CDN mit starker europäischer Präsenz die bestmögliche Erfahrung für Ihr primäres Publikum.",[16,973,974,977,978,983],{},[409,975,976],{},"Bereit, Ihre Core Web Vitals zu verbessern?"," ",[38,979,982],{"href":980,"rel":981},"https:\u002F\u002Fwww.euroracloud.eu",[42],"Testen Sie EuroraCloud 14 Tage kostenlos"," und erleben Sie den Unterschied, den ein European-first CDN machen kann.",[414,985],{},[16,987,988],{},[191,989,990,991,995],{},"Fragen zur Optimierung Ihrer Core Web Vitals? Kontaktieren Sie unser Performance-Team unter ",[38,992,994],{"href":993},"mailto:support@euroracloud.eu","support@euroracloud.eu"," helfen Ihnen gerne.",[997,998,999],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":121,"searchDepth":122,"depth":122,"links":1001},[1002,1007,1012,1018,1019,1020,1021],{"id":424,"depth":122,"text":425,"children":1003},[1004,1005,1006],{"id":432,"depth":830,"text":433},{"id":470,"depth":830,"text":471},{"id":508,"depth":830,"text":509},{"id":543,"depth":122,"text":544,"children":1008},[1009,1010,1011],{"id":550,"depth":830,"text":551},{"id":607,"depth":830,"text":608},{"id":663,"depth":830,"text":664},{"id":705,"depth":122,"text":706,"children":1013},[1014,1015,1016,1017],{"id":712,"depth":830,"text":713},{"id":747,"depth":830,"text":748},{"id":781,"depth":830,"text":782},{"id":808,"depth":830,"text":809},{"id":836,"depth":122,"text":837},{"id":878,"depth":122,"text":879},{"id":914,"depth":122,"text":915},{"id":964,"depth":122,"text":965},null,"2026-02-09","Veröffentlicht: 9. Februar 2026 | Kategorie: Performance | Lesezeit: 8 Minuten",{},"\u002Fblog\u002Fde\u002Fcore-web-vitals-cdn",{"title":403,"description":1024},"core-web-vitals-wie-ein-cdn-hilft","blog\u002Fde\u002Fcore-web-vitals-cdn",[1031,1032,1033],"CDN","Performance","Web Security","m4V3LhbvOpRFlTp5KKyIqZzuOR4puON7yhVuRnhUKjY",1785141125635]