Edit: Voglio solo premettere una cosa
il caricamento di immagini/miniature funziona perfettamente dalla mia stessa IP con qualsiasi browser basato su Chromium. Sembra un problema legato alla policy "Opaque Response Blocking" (ORB) di Firefox in reazione alla ricezione di un
.
In Mozilla Firefox non riesco a caricare nessuna immagine di goonbox/cuckcapital a meno che il .JPG di cuckcapital non venga caricato direttamente in una sua nuova scheda senza referer (non carica le immagini a prescindere che ublock origin/umatrix/la Protezione antitracciamento integrata di FF siano attivi o disattivati). Questo è l'URL con cui ho testato:
https://goonbox.cr/img/t2IWpU5
Se clicco su "download image", ottengo questo:

Se copio l'URL del jpg (
https://simp6.cuckcapital.cr/images4/29ebf49d-5622-4cb9-a5b6-c6621db4816c.jpg ) dalla pagina "Download Image", riesco a caricarlo incollandolo in una sua nuova scheda. Però, siccome Cloudflare restituisce "no-cache" nell'header di risposta, non posso semplicemente tornare su goonbox, ricaricare e aspettarmi che la mia copia in cache locale compaia in quella pagina dopo aver caricato l'immagine direttamente nella sua scheda.
----- Risposta dell'IA qui sotto (
Non so se sia utile in qualche modo ) -----
Il problema è che
simp6.cuckcapital.cr sta rifiutando le richieste cross-origin da goonbox.cr servendo un errore JSON 403 invece di un file immagine, il che fa scattare la rigida policy
Opaque Response Blocking (ORB) di Firefox.
Ecco un riepilogo delle modifiche esatte che l'ingegnere può fare, suddivise in base a dove vanno applicate:
Opzione 1: Modifiche su
(L'host delle immagini — Consigliato)
Questo è il punto più efficace per risolvere il problema. Il server delle immagini deve dire ai browser che
può incorporare questi file.
- Aggiungere header CORS: Configurare il web server (Nginx, Apache o Node.js) che ospita le immagini per consentire richieste cross-origin dal sito front-end. Deve inviare questi header con ogni risposta di immagine:
http
Codice:
Access-Control-Allow-Origin: https://goonbox.cr
Access-Control-Allow-Methods: GET, OPTIONS
- Correggere i MIME-Type di fallback: Attualmente, quando una richiesta fallisce o è limitata, il server risponde con
Codice:
Content-Type: application/json
. L'ingegnere dovrebbe cambiare il comportamento del server in modo che, se una richiesta fallisce, serva un'immagine di fallback standard (come un
o
) con un MIME-type corretto come
o
. Questo impedisce a Firefox di far scattare il blocco di sicurezza ORB.
Opzione 2: Modifiche su Cloudflare (Il livello di sicurezza)
Se
usa Cloudflare, probabilmente è la
Hotlink Protection o il
Web Application Firewall (WAF) di Cloudflare a generare quella pagina di errore JSON
.
- Creare una regola WAF Skip: L'ingegnere dovrebbe andare nella dashboard di Cloudflare per
e navigare su Security > WAF > Custom Rules. Può creare una regola che permetta le richieste provenienti da GoonBox:
- Campo:
o
- Operatore:
- Valore:
- Azione:
(Hotlink Protection / Managed Rules)
- Regolare la Hotlink Protection: Se hanno attivo l'interruttore globale "Hotlink Protection" sotto Scrape Shield, possono spegnerlo e sostituirlo con una regola firewall personalizzata che metta esplicitamente in whitelist i domini fidati come
.
Opzione 3: Modifiche su goonbox.cr (Il sito front-end)
Se l'ingegnere controlla solo il sito front-end (goonbox.cr), può forzare il browser a omettere gli header di tracciamento in modo che l'host delle immagini non si accorga che la richiesta è cross-origin.
- Applicare una Referrer Policy globale: Aggiungere un tag <meta> nel <head> del sito per istruire il browser a non rivelare mai l'origine agli elementi immagine:
html
Codice:
<meta name="referrer" content="no-referrer">
- Aggiornare i tag immagine singolarmente: In alternativa, possono aggiungere l'attributo referrerpolicy direttamente ai tag HTML immagine che caricano da quel server:
html
Codice:
<img src="https://cuckcapital.cr" referrerpolicy="no-referrer">
Nota: Se Cloudflare controlla metadati avanzati come
Codice:
Sec-Fetch-Site: cross-site
, questo trucco front-end da solo potrebbe non funzionare, quindi l'Opzione 1 o l'Opzione 2 sarebbero molto più affidabili.