Defaults.Exposed › Rešenja › Content-Security-Policy (CSP)

Kako popraviti Content-Security-Policy (CSP)

Content Security Policy je bezbednosno pravilo koje vaš sajt predaje pretraživaču svakog posjetioca, govoreći mu tačno koji kod je dozvoljeno da se izvršava. Bez njega, ako ikad nešto zloćudno dospije na stranicu — putem komentarskog polja, hakovanog plugina ili skripte treće strane — pretraživač će ga slobodno izvršiti, uključujući kod koji tiho prikuplja kartične podatke i lozinke vaših kupaca dok ih upisuju, i pored toga što je katanac i dalje prikazan.

Suština za vaše poslovanje: Ako je vaš sajt ikad dira, zloćudni kod može čitati kartične i login podatke vaših kupaca direktno s vašeg checkoutа dok sve izgleda potpuno normalno — ostavljajući vas s chargebackima, prijavama prevare, prijavljivim prodorom podataka i neuspehom provere koji bezbednosni timovi većih klijenata koriste da zaustave ili ubiju posao.

Šta vam ovo može koštati

• Skriven kod klizne na jednu od vaših stranica i tiho kopira svaki broj kartice i lozinku koje vaši kupci unesu na checkoutu, šaljući ih napadaču u realnom vremenu dok vaš sajt izgleda i radi savršeno — saznate tek nedeljama kasnije kad vaš provajder plaćanja pozove zbog grupe prevara.
• Prevarant ubacuje lažnu formu 'platite ovde' na vaš pravi sajt koja hvata plaćanja na njihov račun; kupci misle da su vama platili, okrivljuju vas kad roba ne stigne i traže povrat.
• Bezbednosni tim većeg klijenta skenira vaš sajt, vidi da ova osnovna zaštita nije uključena i to flaguje — zaustavljajući ili gubeći vam ugovor dok ne možete dokazati da je ispravno.
• Proboj praćen do nedostajuće standardne zaštite postaje prijavivi incident: pitanja regulatora, obavještavanja kupaca i reputacioni udar koji košta mnogo više nego besplatna popravka.

Zašto je to važno. Katanac dokazuje da je veza s vašim sajtom privatna, ali ništa ne kontroliše koji kod se izvršava jednom kad je posjetilac na stranici. Content Security Policy je zaštita koja to radi — govori pretraživačima da ignorišu svaku skriptu koja nije došla od izvora kojima vjerujete, pa jedno izmijenjeno polje, oglas ili plugin ne može biti pretvoren u alat za krađu novca i podataka vaših kupaca. To je bodovana provjera na vašem scorecardu, vrijedi prave bodove, i jedna je od prvih stvari koje profesionalna bezbednosna revizija traži.

Šta je ovo, jednostavnim rečima

Kad neko posjeti vaš sajt, pretraživač preuzima vašu stranicu i izvršava sav kod na njoj — skripte koje čine padajuće meniije, dugmad, forme za plaćanje i sve ostalo. Po defaultu, pretraživač im svemu vjeruje. Nema načina znati koji je kod zaista vaš, a koji je ubacio neko drugi.

Content Security Policy (često skraćeno CSP) je kratka lista pravila koje vaš sajt prilaže svakoj stranici, govoreći pretraživaču: “izvršavaj samo kod s ovih izvora koje sam odobrio, i odbij sve ostalo.” To je razlika između noćnog kluba koji pušta svakoga i onog koji ima listu gostiju na vratima.

Razlog zbog kojeg je ovo toliko bitno je što se sajtovi stalno diraju — ne uvek hakovanjem servera, već kroz zadnja vrata koja većina sajtova ostavlja otvorena: polje za komentare, polje za pretragu, zastarjeli plugin, skripta treće strane za oglase ili analitiku, ili chat widget. Ako napadač postavi i jednu liniju svog koda na jednu od vaših stranica, pretraživač ga izvršava kao da je vaš. Odatle može čitati sve što vaši kupci upisuju — brojeve kartica, lozinke, adrese — i tiho slati drugamo. Content Security Policy zatvara ta vrata odbijanjem izvršavanja bilo čega od izvora koji niste odobrili.

Šta vam ovo može koštati

Ovo nije apstraktno. Napad koji Content Security Policy sprečava — kod ubačen u stranicu koji krade podatke od vaših kupaca — stoji iza nekih od najvećih proboja skimminga kartica na rekord. Evo kako to obično ide za normalno preduzeće:

• Nevidljivi checkout skimmer. Napadač provuče nekoliko linija koda na vašu stranicu checkoutа putem ranjivog plugina ili kompromitovane skripte treće strane. Svaki broj kartice, ime i CVV koje vaši kupci upisuju kopira se i šalje napadaču u realnom vremenu. Vaš sajt izgleda i funkcioniše savršeno; katanac je tu. Otkrijete nedeljama kasnije kad vas vaš provajder plaćanja nazove zbog grupe prijava prevare. Sada se suočavate s chargebackima, prisilnom bezbednosnom revizijom, mogućim gubitkom prava na obradu kartica i prodorom koji možda ste zakonski obavezni prijaviti.

• Lažna forma za plaćanje. Prevarant ubaci uvjerljiv “platite ovdje” okvir na vaš pravi sajt. Kupci unesu podatke vjerujući vašem brendu; novac i podaci idu napadaču. Kupci vas okrivljuju — i ne griješe, jer se desilo na vašem sajtu.

• Izgubljeni ugovor. Bezbednosni tim većeg potencijalnog klijenta vrši automatizovano skeniranje vašeg sajta kao dio vendor due diligence. Nedostajuća Content Security Policy odmah se pojavljuje kao visoka ozbiljnost. Za nabavnog ili bezbednosnog recenzenta, ta jedna nedostajuća zaštita čita se kao “ovaj dobavljač ne radi osnove” — i posao zastaje dok traže sanaciju, ili tiho ide kod konkurenta koji je prošao.

• Prijavivi proboj. Kad je proboj podataka praćen do nedostajuće, standardne, besplatne zaštite, prestaje biti loša sreća i počinje izgledati kao nemar. To mijenja pitanja regulatora, obavezu obavještavanja kupaca i trošak — i novčanu kaznu i reputacioni udar, koji traje dugo nakon što je incident zatvoren.

• Kompromitovani oglas ili widget. Mnogi sajtovi učitavaju kod od spoljnih strana — reklamne mreže, fontovi, podrška za chat, analitika. Ako je iko od njih probijen, zloćudni kod direktno jaše u vaše stranice. Content Security Policy ograničava blast radius dozvoljavajući samo specifične spoljne izvore kojima vjerujete, pa proboj jednog dobavljača ne postaje automatski i vaš.

Šta je to zapravo (detalj)

Content Security Policy se isporučuje kao jedan HTTP response header — linija koju vaš web server šalje sa svakom stranicom. Njegova vrijednost je skup direktiva, svaka imenujući vrstu sadržaja i dozvoljene izvore za njega. Na primjer:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Jednostavnim rečima, to kaže: po defaultu učitavaj stvari samo s mog sajta; izvršavaj skripte samo s mog sajta; ne dozvoli stare plugine; i ne dozvoli drugim sajtovima da moj sajt embed-uju u frame.

Kako izgleda “dobro”. Naša provjera ne gleda samo prisustvo headera — čita politiku direktivu po direktivu i boduje koliko je zapravo jaka, kao što bi bezbednosni recenzent. Jaka politika:

• Postavlja restriktivnu osnovu (default-src 'self') i samo je širi za specifične pouzdane treće strane koje zaista koristite.
• Izbjegava rupe. Ne koristi 'unsafe-inline' ili 'unsafe-eval' za skripte, i ne koristi wildcard (*) ili gole scheme izvore (poput https:) za skripte — oni efektivno ponovo otvaraju vrata koja politika treba zatvoriti. Gdje su inline skripte zaista potrebne, koristi nonce ili hash da samo vaš specifičan odobren kod može da se izvrši.
• Zaključava framing s frame-ancestors 'self' (ovo blokira i napad “embed-ujte vaš sajt da prevarite kupce”) i onemogućava legacy plugine s object-src 'none'.
• Primjenjuje, a ne samo report-only. Content-Security-Policy-Report-Only header samo posmatra; ne pruža nikakvu runtime zaštitu. Naša provjera mu daje mali djelić kredita i nikad ga ne bilježi kao prolaz. Zaštićeni ste tek kad je politika primijenjena.

Politika koja postoji, ali se oslanja na 'unsafe-inline', 'unsafe-eval' ili wildcards, i dalje će se loše bodovati — jer u praksi pruža malo stvarne zaštite. Cilj je tesna politika, ne samo bilo koja politika.

Kako popraviti (besplatno, ~1–2 sata)

Prosledite ovo vašoj IT osobi ili ko god pokreće vaš sajt — sama popravka je potpuno besplatna. Naplaćujemo jedino praćenje da ostane na snazi i ispravno tokom vremena; uključivanje ničeg ne košta. Razlog što ovo traje sat ili dva umjesto minuta je pažljivi probni korak koji sprečava slučajno blokiranje dijelova vašeg sajta.

1. Počnite u report-only modu — nemojte još primijeniti. Dodajte Content-Security-Policy-Report-Only response header. Ovo posmatra i zapisuje šta bi bilo blokirano, a da zapravo ne blokira ništa, pa živi sajt nastavlja raditi dok učite od čega svaka stranica zaista zavisi. (Važno: report-only sam po sebi ne daje posjetiocima zaštitu — to je samo siguran prvi korak.)

2. Izgradite politiku od onoga što vaš sajt zapravo koristi. Pregledajte izvještaje da pronađete svaki legitimni izvor skripti, stilova, fontova i slika — vaš domen, vaša analitika, vaš provajder plaćanja, vaš host fontova, vaš chat widget — i navedite ih kao dozvoljene izvore. Solidna polazna tačka je default-src 'self' plus eksplicitni unosi za pouzdane treće strane koje zaista koristite.

3. Izbjegavajte rupe koje poništavaju cijelu postu. Klonite se 'unsafe-inline' i 'unsafe-eval' za skripte, i izbjegavajte wildcard izvore poput * i gole scheme poput https: za skripte — oni ponovo otvaraju tačno prazninu koju politika treba zatvoriti. Gdje su inline skripte neizbježne, koristite nonce ili hash da samo vaš specifičan odobren kod radi.

4. Zaključajte framing i plugine. Dodajte frame-ancestors 'self' (ovo sprečava i da drugi sajtovi embed-uju vaš da prevare vaše kupce, i zadovoljava vezanu provjeru clickjackinga) i object-src 'none' za blokiranje legacy napada baziranih na pluginima.

5. Prebacite se s report-only na primjenu. Jednom kad su izvještaji čisti i sajt radi, promijenite ime headera s Content-Security-Policy-Report-Only na Content-Security-Policy. Ovo je korak koji zapravo pruža zaštitu — report-only politika sama po sebi ne, i neće proći provjeru.

   Gdje postaviti header zavisi od platforme:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → postavite Content-Security-Policy.
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): dodajte prilagođeni HTTP response header nazvan Content-Security-Policy s politikom kao vrijednošću.
   • Google Workspace / Microsoft 365: ovi pokreću vaš imejl, ne vaš javni sajt, pa se politika postavlja gdje god je vaš sajt zapravo hostovan (Cloudflare ili vaš web host gore), a ne u vašoj imejl admin konzoli.

6. Ponovo proverite vaš domen da potvrdite da politika sada prikazuje kao uključena i primijenjena, bez slabljenja rupa.

Česte greške

• Zaustavljanje na report-only. Najčešća greška: politika je dodana u report-only modu, svi nastave dalje, a sajt nikad zapravo nije zaštićen. Report-only ništa ne blokira. Morate prebaciti na primjenu.
• Posizanje za 'unsafe-inline' da bi “samo radilo”. Kad politika blokira legitimnu inline skriptu, brza popravka je dozvoliti sve inline skripte — ali to ponovo otvara tačno rupu koju politika trebala zatvoriti. Koristite nonce ili hash umjesto toga.
• Korišćenje wildcarda. Golo * (ili https:) u script-src dozvoljava skripte sa svugdje, što znači da politika pruža gotovo nikakvu stvarnu zaštitu i i dalje će se loše bodovati.
• Zaboravljanje spoljnih izvora. Primjena stroge politike bez prethodnog navođenja legitimnih spoljnih servisa koje koristite (analitika, fontovi, payment widgeti) može pokvariti dijelove vašeg sajta — što je tačno razlog zašto probni report-only korak postoji.
• Postavljanje samo na početnoj stranici. Politika treba pokriti svaku stranicu, posebno checkout, prijavu i stranice naloga — jer su one vrijedne napada.
• Tretiranje kao zamjenu za katanac. Content Security Policy i HTTPS/HSTS štite različite stvari. Trebate sve; jedno ne pokriva za drugo.

Često postavljana pitanja