Was bedeutet 'navigation blocked by cross origin opener policy'?

Question

Was bedeutet 'navigation blocked by cross origin opener policy'?

Antwort

Verwandte Fragen

Wie prüft man, ob admin-ajax.php erreichbar ist und ein REST-Nonce gültig bleibt?

Welche Referrer-Policy ist besser: same-origin oder strict-origin-when-cross-origin?

Sicheres Newsletter-Script in PHP?

Welche Optionen hat SameSite?

Was bedeutet Webkit in einer CSS-Datei?

Wie erstelle ich eine HTML-Datei, die sich ohne Tabs im Browser öffnet?

Eingangscode für HTML-Seite?

Accepted Answer

Die Fehlermeldung „navigation blocked by cross origin opener policy“ bedeutet, dass eine Webseite versucht hat, eine andere Seite zu laden oder zu öffnen (z. B. per `window.open` oder durch das Setzen von `window.location`), dies aber vom Browser blockiert wurde. Der Grund ist die sogenannte **Cross-Origin Opener Policy** (COOP). **Hintergrund:** COOP ist eine Sicherheitsrichtlinie, die Webseiten davor schützt, dass andere Seiten (insbesondere von anderen Ursprüngen/Domains) auf bestimmte Browser-Objekte oder -Kontexte zugreifen können. Sie verhindert z. B. Angriffe wie Cross-Site Leaks (XS-Leaks). **Wann tritt der Fehler auf?** - Wenn eine Seite mit einer bestimmten COOP-Einstellung (z. B. `Cross-Origin-Opener-Policy: same-origin`) versucht, eine Seite mit einer anderen COOP-Einstellung zu öffnen oder zu navigieren. - Wenn die Ursprünge (Domains) unterschiedlich sind und die COOP-Richtlinien nicht kompatibel sind. **Was tun?** - Prüfe die HTTP-Header `Cross-Origin-Opener-Policy` und ggf. auch `Cross-Origin-Embedder-Policy` auf beiden Seiten. - Stelle sicher, dass die Richtlinien kompatibel sind, wenn eine Navigation oder ein Öffnen von Fenstern über verschiedene Ursprünge hinweg notwendig ist. **Weitere Infos:** - [MDN: Cross-Origin Opener Policy (COOP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) - [Google Web Fundamentals: COOP and COEP](https://web.dev/coop-coep/) Kurz gesagt: Die Fehlermeldung schützt vor Sicherheitsrisiken, indem sie verhindert, dass Seiten mit unterschiedlichen Ursprüngen und COOP-Einstellungen miteinander interagieren.

Accepted Answer

Um sicherzustellen, dass der **Rest-Nonce** in einer WordPress-Umgebung gültig bleibt und die Datei `admin-ajax.php` erreichbar ist, sind folgende Schritte notwendig: ### 1. Erreichbarkeit von `... [mehr]

Accepted Answer

Um sicherzustellen, dass der **Rest-Nonce** in einer WordPress-Umgebung gültig bleibt und die Datei `admin-ajax.php` erreichbar ist, sind folgende Schritte notwendig: ### 1. Erreichbarkeit von `admin-ajax.php` prüfen - Rufe die URL `https://deine-domain.de/wp-admin/admin-ajax.php` im Browser auf. - Bei einer leeren Seite ohne Fehlermeldung ist die Datei erreichbar. - Alternativ kann ein einfacher `GET`-Request per `curl` oder einem anderen Tool gesendet werden: ```bash curl -I https://deine-domain.de/wp-admin/admin-ajax.php ``` Der Statuscode sollte `200 OK` sein. ### 2. Gültigkeit des Nonce prüfen Ein **Nonce** (Number used once) ist ein Sicherheits-Token, das WordPress für AJAX- und REST-API-Anfragen verwendet. Er ist zeitlich begrenzt gültig (standardmäßig 12 oder 24 Stunden). - Der Nonce wird meist per JavaScript-Variable oder als Data-Attribut im HTML ausgegeben, z.B.: ```js var restNonce = '<?php echo wp_create_nonce( 'wp_rest' ); ?>'; ``` - Bei einer AJAX- oder REST-Anfrage wird der Nonce im Header (`X-WP-Nonce`) oder als POST-Parameter mitgesendet. **Prüfung:** - Sende eine Testanfrage mit dem aktuellen Nonce an den gewünschten Endpoint (z.B. `/wp-json/wp/v2/posts`). - Wenn der Nonce abgelaufen oder ungültig ist, gibt WordPress einen Fehler wie `rest_cookie_invalid_nonce` oder `rest_nonce_invalid` zurück. - Beispiel mit `curl`: ```bash curl -H "X-WP-Nonce: DEIN_NONCE" https://deine-domain.de/wp-json/wp/v2/posts ``` - Bei Erfolg erhältst du die gewünschten Daten, bei Fehler eine JSON-Antwort mit einer Fehlermeldung. ### 3. Nonce regelmäßig erneuern Da der Nonce abläuft, sollte er regelmäßig (z.B. per JavaScript-Timer oder nach bestimmten Aktionen) vom Server neu angefordert werden. Das geschieht meist über einen eigenen Endpoint oder durch erneutes Laden der Seite. **Typischer Ablauf:** - Über JavaScript wird ein AJAX-Request an einen eigenen Endpoint (z.B. `restNonceEndpoint`) gesendet. - Der Server gibt einen neuen Nonce zurück. - Der neue Nonce wird im Frontend gespeichert und für weitere Anfragen verwendet. **Beispiel für das Nachladen eines Nonce:** ```js fetch('/wp-admin/admin-ajax.php?action=refresh_nonce') .then(response => response.json()) .then(data => { window.restNonce = data.nonce; }); ``` ### Zusammenfassung - **admin-ajax.php** muss per HTTP erreichbar sein. - **Nonce** muss bei jeder Anfrage mitgesendet und regelmäßig erneuert werden. - Die Gültigkeit des Nonce kann durch eine Testanfrage geprüft werden. - Bei Fehlern gibt WordPress eine entsprechende Fehlermeldung zurück. **Weitere Infos:** - [WordPress Nonces](https://developer.wordpress.org/plugins/security/nonces/) - [AJAX in WordPress](https://developer.wordpress.org/plugins/javascript/ajax/) - [REST API Nonces](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/) Falls du eine konkrete Fehlermeldung erhältst, kann diese helfen, das Problem genauer einzugrenzen.

Accepted Answer

Die Direktive `add_header Referrer-Policy ... always;` in der Nginx-Konfiguration legt fest, wie der Referrer-Header beim Laden von Ressourcen an andere Seiten gesendet wird. Beide von dir genannten O... [mehr]

Accepted Answer

Die Direktive `add_header Referrer-Policy ... always;` in der Nginx-Konfiguration legt fest, wie der Referrer-Header beim Laden von Ressourcen an andere Seiten gesendet wird. Beide von dir genannten Optionen sind gängige Einstellungen, unterscheiden sich aber im Grad der Privatsphäre und Funktionalität: **1. `add_header Referrer-Policy "same-origin" always;`** - Der Referrer-Header wird **nur** gesendet, wenn die Ziel-URL die gleiche Origin (gleiche Domain, Protokoll und Port) hat. - Bei Anfragen zu anderen Origins wird **kein** Referrer-Header gesendet. - **Vorteil:** Maximale Privatsphäre für Nutzer, da keine Referrer-Informationen an externe Seiten weitergegeben werden. - **Nachteil:** Manche externe Dienste (z.B. Analytics, Payment) könnten auf Referrer-Informationen angewiesen sein. **2. `add_header Referrer-Policy "strict-origin-when-cross-origin" always;`** - Bei Anfragen zur gleichen Origin wird der vollständige Referrer-Header gesendet. - Bei Anfragen zu einer anderen Origin wird **nur die Origin** (z.B. `https://example.com/`) gesendet, nicht der vollständige Pfad. - Bei unsicheren (HTTP) zu sicheren (HTTPS) Anfragen wird **kein** Referrer gesendet. - **Vorteil:** Gute Balance zwischen Privatsphäre und Funktionalität. Externe Seiten sehen, von welcher Domain der Traffic kommt, aber nicht die genaue URL. - **Nachteil:** Etwas weniger Privatsphäre als bei `same-origin`, aber in der Praxis oft ausreichend. **Empfehlung:** - Wenn maximale Privatsphäre gewünscht ist und keine externen Dienste auf Referrer angewiesen sind: `add_header Referrer-Policy "same-origin" always;` - Für die meisten Websites ist `add_header Referrer-Policy "strict-origin-when-cross-origin" always;` die bessere Wahl, da sie einen guten Kompromiss zwischen Datenschutz und Funktionalität bietet. **Weitere Infos:** - [MDN Web Docs: Referrer-Policy](https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Referrer-Policy) - [Nginx Dokumentation: add_header](https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header)

Accepted Answer

Ein sicheres Newsletter-Script in PHP sollte mehrere Aspekte berücksichtigen, um die Sicherheit und Funktionalität zu gewährleisten. Hier ist ein einfaches Beispiel, das grundlegende Si... [mehr]

Accepted Answer

Ein sicheres Newsletter-Script in PHP sollte mehrere Aspekte berücksichtigen, um die Sicherheit und Funktionalität zu gewährleisten. Hier ist ein einfaches Beispiel, das grundlegende Sicherheitsmaßnahmen implementiert: ```php <?php // Datenbankverbindung $host = 'localhost'; $db = 'deine_datenbank'; $user = 'dein_benutzername'; $pass = 'dein_passwort'; try { $pdo = new PDO("mysql:host=$host;dbname=$db", $user, $pass); $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); } catch (PDOException $e) { die("Verbindung fehlgeschlagen: " . $e->getMessage()); } // E-Mail-Adresse verarbeiten if ($_SERVER["REQUEST_METHOD"] == "POST") { $email = filter_var(trim($_POST["email"]), FILTER_SANITIZE_EMAIL); // E-Mail-Validierung if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { die("Ungültige E-Mail-Adresse."); } // E-Mail in die Datenbank einfügen $stmt = $pdo->prepare("INSERT INTO newsletter (email) VALUES (:email)"); $stmt->bindParam(':email', $email); try { $stmt->execute(); echo "Danke für deine Anmeldung!"; } catch (PDOException $e) { die("Fehler beim Einfügen: " . $e->getMessage()); } } ?> <!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <title>Newsletter Anmeldung</title> </head> <body> <form action="" method="post"> <label for="email">E-Mail-Adresse:</label> <input type="email" name="email" required> <button type="submit">Anmelden</button> </form> </body> </html> ``` ### Sicherheitsmaßnahmen: 1. **E-Mail-Validierung**: Überprüfe, ob die eingegebene E-Mail-Adresse gültig ist. 2. **Prepared Statements**: Verhindert SQL-Injection, indem Parameter gebunden werden. 3. **Datenbankverbindung**: Nutze PDO für eine sichere Datenbankverbindung. 4. **Sanitization**: Bereinige die Eingaben, um schädliche Daten zu entfernen. ### Weitere Empfehlungen: - Implementiere ein Double-Opt-In-Verfahren, um sicherzustellen, dass die E-Mail-Adresse tatsächlich dem Benutzer gehört. - Schütze das Script vor CSRF-Angriffen, indem du ein Token für Formulare verwendest. - Stelle sicher, dass die Datenbankverbindung und die Datenbank selbst sicher konfiguriert sind. Diese Vorlage bietet einen grundlegenden Rahmen, den du an deine spezifischen Anforderungen anpassen kannst.

Accepted Answer

Die `SameSite`-Attributoptionen für Cookies sind: 1. **Strict**: Cookies werden nur gesendet, wenn die Anfrage von der gleichen Site stammt. Dies bedeutet, dass Cookies nicht bei Cross-Site-Anfr... [mehr]

Accepted Answer

Die `SameSite`-Attributoptionen für Cookies sind: 1. **Strict**: Cookies werden nur gesendet, wenn die Anfrage von der gleichen Site stammt. Dies bedeutet, dass Cookies nicht bei Cross-Site-Anfragen gesendet werden, was das Risiko von CSRF-Angriffen verringert. 2. **Lax**: Cookies werden bei Navigationsanfragen (z. B. beim Klicken auf einen Link) gesendet, jedoch nicht bei anderen Arten von Cross-Site-Anfragen (z. B. bei AJAX-Anfragen). Dies bietet einen Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. 3. **None**: Cookies werden bei allen Anfragen gesendet, unabhängig von der Herkunft. Wenn `None` verwendet wird, muss das Cookie auch als `Secure` markiert sein, was bedeutet, dass es nur über HTTPS-Verbindungen gesendet wird. Diese Optionen helfen, die Sicherheit von Cookies zu erhöhen und das Risiko von Angriffen zu minimieren.

Accepted Answer

`-webkit-` ist ein Präfix, das in CSS verwendet wird, um spezifische Eigenschaften und Funktionen zu kennzeichnen, die für WebKit-basierte Browser wie Safari und ältere Versionen von Ch... [mehr]

Accepted Answer

`-webkit-` ist ein Präfix, das in CSS verwendet wird, um spezifische Eigenschaften und Funktionen zu kennzeichnen, die für WebKit-basierte Browser wie Safari und ältere Versionen von Chrome entwickelt wurden. Es handelt sich um eine Art von Vendor-Prefix, der es Entwicklern ermöglicht, experimentelle oder nicht standardisierte CSS-Eigenschaften zu nutzen, die möglicherweise noch nicht in allen Browsern unterstützt werden. Beispiele für CSS-Eigenschaften mit dem `-webkit-` Präfix sind: - `-webkit-transition`: für Übergangseffekte. - `-webkit-transform`: für Transformationen wie Skalierung oder Drehung. - `-webkit-border-radius`: für abgerundete Ecken. Die Verwendung von Vendor-Prefixes ist oft notwendig, um sicherzustellen, dass bestimmte Stile in verschiedenen Browsern konsistent dargestellt werden. Es ist jedoch ratsam, die Verwendung solcher Präfixe auf ein Minimum zu beschränken und die standardisierten Eigenschaften zu bevorzugen, sobald sie allgemein unterstützt werden.

Accepted Answer

Um eine HTML-Datei zu erstellen, die sich ohne Tabs im Browser öffnet, kannst du die `window.open()`-Methode in JavaScript verwenden, um ein neues Fenster zu öffnen. Hier ist ein einfaches B... [mehr]

Accepted Answer

Um eine HTML-Datei zu erstellen, die sich ohne Tabs im Browser öffnet, kannst du die `window.open()`-Methode in JavaScript verwenden, um ein neues Fenster zu öffnen. Hier ist ein einfaches Beispiel, wie du das umsetzen kannst: 1. Erstelle eine HTML-Datei, z.B. `index.html`. 2. Füge den folgenden Code in die Datei ein: ```html <!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Ohne Tabs öffnen</title> <script> function openWithoutTabs() { window.open('deine-seite.html', '_blank', 'toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=800,height=600'); } </script> </head> <body> <h1>Willkommen!</h1> <button onclick="openWithoutTabs()">Öffne Seite ohne Tabs</button> </body> </html> ``` 3. Erstelle eine weitere HTML-Datei, z.B. `deine-seite.html`, die du im neuen Fenster anzeigen möchtest. Wenn du nun die `index.html` öffnest und auf den Button klickst, wird `deine-seite.html` in einem neuen Fenster ohne die typischen Browser-Tabs geöffnet. Beachte, dass die Möglichkeit, Fenster ohne Tabs zu öffnen, von den Browsereinstellungen und -richtlinien abhängt und nicht immer garantiert werden kann.

Accepted Answer

Um einen einfachen Eingangscode für eine HTML-Seite zu erstellen, kannst du ein Formular verwenden, das einen Benutzernamen und ein Passwort abfragt. Hier ist ein Beispiel: ```html <!DOCTYPE... [mehr]

Accepted Answer

Um einen einfachen Eingangscode für eine HTML-Seite zu erstellen, kannst du ein Formular verwenden, das einen Benutzernamen und ein Passwort abfragt. Hier ist ein Beispiel: ```html <!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <meta name="" content="width=device-width, initial-scale=1.0"> <title>Eingangscode</title> </head> <body> <h2>Bitte anmelden</h2> <form action="deine_zielseite.html" method="post"> <label for="username">Benutzername:</label><br> <input type="text" id="username" name="username" required><br><br> <label for="password">Passwort:</label><br> <input type="password" id="password" name="password" required><br><br> <input type="submit" value="Einloggen"> </form> </body> </html> ``` In diesem Beispiel wird ein einfaches Anmeldeformular erstellt. Du kannst die `action`-Eigenschaft des Formulars anpassen, um die Daten an die gewünschte Zielseite zu senden. Beachte, dass dies nur eine grundlegende HTML-Struktur ist und keine Sicherheitsmaßnahmen wie die Validierung von Benutzerdaten oder die Verschlüsselung von Passwörtern enthält.