Edit: Vorab möchte ich nur sagen
dass das Laden von Bildern/Thumbnails von derselben IP mit jedem Chromium-basierten Browser einwandfrei funktioniert. Das scheint ein Problem mit der "Opaque Response Blocking"-Richtlinie (ORB) von Firefox zu sein, als Reaktion auf den Empfang eines
.
In Mozilla Firefox kann ich keine goonbox/cuckcapital-Bilder laden, außer das cuckcapital-.JPG wird direkt in einem eigenen neuen Tab ohne Referer geladen (Bilder laden nicht, egal ob ublock origin/umatrix/Firefox' eingebauter Tracking-Schutz an oder aus ist). Das ist die URL, mit der ich getestet habe:
https://goonbox.cr/img/t2IWpU5
Wenn ich auf "download image" klicke, bekomme ich das hier:

Wenn ich die jpg-URL (
https://simp6.cuckcapital.cr/images4/29ebf49d-5622-4cb9-a5b6-c6621db4816c.jpg ) von der "Download Image"-Seite kopiere, kann ich sie laden, indem ich sie in einen eigenen neuen Tab einfüge. Aber da Cloudflare "no-cache" im Response-Header zurückgibt, kann ich nicht einfach zurück zu goonbox gehen, aktualisieren und erwarten, dass meine lokale Cache-Kopie auf der Seite auftaucht, nachdem ich das Bild direkt in einem eigenen Tab geladen habe.
----- KI-Antwort unten (
Keine Ahnung, ob das überhaupt hilft ) -----
Das Problem ist, dass
simp6.cuckcapital.cr Cross-Origin-Anfragen von goonbox.cr ablehnt, indem es einen 403-JSON-Fehler statt einer Bilddatei ausliefert, was Firefox' strikte
Opaque-Response-Blocking-Richtlinie (ORB) auslöst.
Hier eine Zusammenfassung der genauen Änderungen, die der Entwickler vornehmen kann, kategorisiert danach, wo sie angewendet werden müssen:
Option 1: Änderungen auf
(dem Bild-Host — empfohlen)
Das ist die effektivste Stelle, um das Problem zu beheben. Der Bildserver muss den Browsern mitteilen, dass
diese Dateien einbetten darf.
- CORS-Header hinzufügen: Den Webserver (Nginx, Apache oder Node.js), der die Bilder hostet, so konfigurieren, dass er Cross-Origin-Anfragen von der Front-End-Seite erlaubt. Er muss diese Header bei jeder Bildantwort senden:
http
Code:
Access-Control-Allow-Origin: https://goonbox.cr
Access-Control-Allow-Methods: GET, OPTIONS
- Fallback-MIME-Types korrigieren: Aktuell antwortet der Server bei einer fehlgeschlagenen oder eingeschränkten Anfrage mit
Code:
Content-Type: application/json
. Der Entwickler sollte das Serververhalten ändern, sodass bei einer fehlgeschlagenen Anfrage ein Standard-Fallback-Bild (wie ein
oder
) mit einem korrekten
- oder
-MIME-Type ausgeliefert wird. Das verhindert, dass Firefox die ORB-Sicherheitssperre auslöst.
Option 2: Änderungen bei Cloudflare (der Sicherheitsschicht)
Wenn
Cloudflare nutzt, erzeugt wahrscheinlich Cloudflares
Hotlink-Schutz oder
Web Application Firewall (WAF) diese
-JSON-Fehlerseite.
- Eine WAF-Skip-Regel erstellen: Der Entwickler sollte ins Cloudflare-Dashboard für
gehen und zu Security > WAF > Custom Rules navigieren. Er kann eine Regel erstellen, die Anfragen von GoonBox erlaubt:
- Feld:
oder
- Operator:
- Wert:
- Aktion:
(Hotlink Protection / Managed Rules)
- Hotlink-Schutz anpassen: Wenn der globale "Hotlink Protection"-Schalter unter Scrape Shield aktiviert ist, kann man ihn ausschalten und durch eine eigene Firewall-Regel ersetzen, die vertrauenswürdige Domains wie
explizit auf die Whitelist setzt.
Option 3: Änderungen auf goonbox.cr (der Front-End-Seite)
Wenn der Entwickler nur die Front-End-Seite (goonbox.cr) kontrolliert, kann er den Browser zwingen, Tracking-Header wegzulassen, damit der Bild-Host nicht merkt, dass die Anfrage Cross-Origin ist.
- Eine globale Referrer Policy anwenden: Ein <meta>-Tag im <head> der Seite hinzufügen, das den Browser anweist, die Herkunft nie an Bildelemente weiterzugeben:
html
Code:
<meta name="referrer" content="no-referrer">
- Bild-Tags einzeln aktualisieren: Alternativ kann man das referrerpolicy-Attribut direkt an die HTML-Bild-Tags hängen, die von diesem Server laden:
html
Code:
<img src="https://cuckcapital.cr" referrerpolicy="no-referrer">
Hinweis: Wenn Cloudflare erweiterte Metadaten wie
Code:
Sec-Fetch-Site: cross-site
prüft, funktioniert dieser Front-End-Trick allein eventuell nicht, daher wären Option 1 oder Option 2 deutlich zuverlässiger.