Limitați rescrierea conținutului de către proxy cu no-transform și HTTPS
Folosiți no-transform pentru a declara o politică de conținut HTTP și HTTPS pentru a proteja conexiunea browserului împotriva modificării paginii în tranzit.
Un proxy care transformă conținut poate modifica un răspuns pe drumul spre browser: recompresă o imagine, rescrie marcajul sau inserează JavaScript de sprijin. O pagină care funcționează într-o rețea și primește marcaj necunoscut în alta poate întâlni exact acest comportament al intermediarului.
Pentru un site pe care îl operați, HTTP oferă o directivă de răspuns explicită:
Cache-Control: no-transform
RFC 9111 cere ca un intermediar care primește această directivă de răspuns să lase conținutul netransformat, indiferent dacă acel intermediar implementează un cache. Este relevant pentru recompresia imaginilor și injectarea de marcaj, nu doar pentru dacă un obiect este stocat.
Păstrați-o împreună cu politica de cache existentă
Dacă un răspuns are deja directive de cache, adăugați cerința în mod deliberat în loc să renunțați la restul politicii. De exemplu, o resursă stocabilă public ar putea avea:
Cache-Control: public, max-age=3600, no-transform
Acest exemplu păstrează o politică de prospețime de o oră și interzice totodată transformarea conținutului. no-transform nu implică no-store și nu dezactivează procesarea obișnuită a transferului. Setați-o pe răspunsurile al căror conținut original contează, inclusiv pe răspunsurile de imagine separate, unde este cazul.
Directiva funcționează prin conformarea intermediarului. Nu împiedică criptografic un dispozitiv de rețea să ignore instrucțiunea.
Protejați și transportul
HTTPS oferă browserului o conexiune cu autentificare și protecție a integrității către partenerul său TLS. Un proxy obișnuit al operatorului care lasă să treacă trafic criptat nu poate insera în tăcere un script în acea conexiune protejată. Păstrați verificarea certificatelor activă; un proxy de inspecție de încredere local care termină TLS este o altă configurație.
Serviți pagina și resursele sale dependente prin HTTPS. Redirecționați vizitatorii HTTP către HTTPS și luați în considerare HSTS pentru o implementare care îl poate susține în mod consecvent. Doar o redirecționare începe cu un schimb HTTP neprotejat pentru un vizitator care a folosit un URL HTTP; o politică HSTS învățată anterior sau preîncărcată schimbă această alegere inițială.
Blocarea unui script injectat poate reduce efectele sale vizibile, dar răspunsul poate conține deja HTML modificat sau URL-uri de imagine rescrise. Înlocuirea unui singur nume vechi de funcție, adăugarea unui comentariu neobișnuit sau maparea unei adrese de injectare istorice nu stabilește integritatea conținutului pentru următorul intermediar.
Când investigați un raport, comparați răspunsul primit cu conținutul intenționat al originii și identificați unde se termină TLS. Această dovadă este mai utilă decât tratarea fiecărui script necunoscut ca o eroare în codul aplicației site-ului însuși.