Web security osnove: šta mora da postoji pre puštanja produkcije

Pre puštanja sajta u produkciju mora da postoji proverljiv bezbednosni minimum: HTTPS, pravilno rešeni nalozi i dozvole, zaštita tajni, bezbedna obrada korisničkog unosa, ažurne zavisnosti, sigurnosna zaglavlja, backup i plan reagovanja. Nije dovoljno da aplikacija „radi“ na staging okruženju; produkcija mora biti podešena tako da ograniči posledice greške i omogući brzo otkrivanje problema.

Ovaj tekst je namenjen vlasnicima projekata, product osobama i development timovima koji žele jasnu web security proveru pre release-a. Ne predstavlja audit niti zamenu za testiranje prema konkretnom riziku. Cilj je da se pre objave ne preskoče kontrole koje treba da budu deo procesa izrade sajta, a ne naknadna improvizacija.

1. Definišite šta štitite i od čega

Bezbednosna provera počinje inventarom, ne instaliranjem dodatka ili generisanjem još jednog izveštaja. Zapišite koje podatke sistem obrađuje, ko ima pristup administraciji, koji servisi komuniciraju sa sajtom i šta bi se dogodilo ako određeni deo prestane da radi ili bude kompromitovan.

• Podaci: kontakt forme, nalozi, sesije, dokumenti, plaćanja, interne beleške i logovi.
• Ulazne tačke: javne stranice, API rute, forme, upload fajlova, webhooks, administracija i integracije.
• Privilegije: vlasnik, urednik, developer, servisni nalog i hosting administrator ne treba automatski da imaju ista prava.
• Zavisnosti: CMS, pluginovi, biblioteke, CDN, analitika, email servis, payment provider i infrastruktura.

Za manje prezentacione sajtove rizik može biti prvenstveno vezan za administraciju, spam, defacement i curenje konfiguracije. Za aplikaciju sa korisničkim nalozima fokus se pomera na autorizaciju, sesije, lične podatke, upload i oporavak. Zato ne postoji jedna checklista koja zamenjuje model pretnji, makar bio jednostavan dokument sa nekoliko scenarija.

2. Produkciona konfiguracija mora biti odvojena od developmenta

Jedna od najčešćih grešaka je kopiranje development podešavanja u produkciju. Produkcija ne treba da prikazuje stack trace, SQL upite, detaljne putanje fajlova ili interne identifikatore korisniku. Debug režim treba isključiti, a greške prikazivati kroz kontrolisanu stranicu i beležiti u sistem kojem imaju pristup samo ovlašćene osobe.

Proverite sledeće pre objave:

• produkcioni domen i poddomeni koriste očekivane vrednosti;
• testni nalozi, demo ključevi i privremene rute su uklonjeni ili zaključani;
• administracija nije dostupna kroz nepotrebne javne endpoint-e;
• server ne izlaže listing direktorijuma, backup arhive, .env fajlove, source mape ili razvojne alate;
• razvojni i produkcioni podaci nisu pomešani;
• promene konfiguracije mogu da se vrate na prethodno poznato stanje.

Konfiguracija treba da bude deo kontrolisanog release procesa. Ako se vrednosti ručno menjaju na serveru bez evidencije, sledeći deploy može vratiti staru ili nesigurnu postavku i otežati istragu incidenta.

3. HTTPS, kolačići i sesije

HTTPS štiti komunikaciju između browsera i servera, ali sam sertifikat ne rešava autorizaciju, malware, lošu konfiguraciju ili ranjivu aplikacionu logiku. Pre produkcije proverite da se osetljive stranice i API pozivi ne učitavaju preko HTTP-a i da se HTTP saobraćaj dosledno preusmerava na HTTPS, uz pažljivu proveru svih integracija i asseta.

Za sesije i kolačiće važe praktična pitanja:

• Da li su kolačići sesije označeni sa Secure, kako se ne bi slali kroz nešifrovan kanal?
• Da li je podešen HttpOnly tamo gde JavaScriptu nije potreban pristup kolačiću?
• Da li je SameSite izabran prema stvarnom scenariju prijave, plaćanja ili cross-site integracije?
• Da li se sesija obnavlja nakon prijave i poništava nakon odjave ili promene privilegija?
• Da li postoji razuman mehanizam za istek sesije i opoziv kompromitovanih sesija?

Ove odluke zavise od arhitekture. Na primer, API koji koriste mobilna aplikacija i browser nema isti model sesije kao klasičan server-rendered sajt. Važno je dokumentovati izabrani model, umesto kombinovanja više mehanizama bez jasne odgovornosti.

4. Autentikacija nije isto što i autorizacija

Autentikacija odgovara na pitanje „ko ste“, dok autorizacija odgovara na pitanje „šta smete da uradite“. Produkcioni test mora pokriti oba sloja. Korisnik ne sme da vidi ili menja tuđi zapis samo zato što je promenio ID u URL-u ili API zahtevu. Svaka osetljiva radnja mora na serveru proveriti identitet i pravo pristupa; sakrivanje dugmeta u interfejsu nije zaštita.

Minimum za naloge i administraciju

• lozinke se ne čuvaju u čistom tekstu, već kroz odgovarajući password hashing mehanizam;
• ne postoji zajednički administratorski nalog bez potrebe i evidencije;
• ponovljeni neuspeli pokušaji prijave imaju kontrolu brzine ili drugi mehanizam za ograničavanje zloupotrebe;
• reset lozinke koristi kratkotrajne, jednokratne tokene i ne otkriva da li nalog postoji;
• privilegovane radnje imaju dodatnu proveru tamo gde je rizik veći;
• promene uloga i pristupa ostavljaju trag u audit logu.

Za kriterijume aplikacione bezbednosti koristan je OWASP Application Security Verification Standard. On može poslužiti kao osnova za izbor kontrola prema riziku, ali nije razlog da se mehanički označi svaka stavka bez razumevanja sistema.

5. Validacija unosa, output encoding i upload fajlova

Sve što dolazi od korisnika, spoljnog servisa ili čak iz baze treba tretirati kao nepouzdano dok se ne proveri u konkretnom kontekstu. Validacija na frontendu poboljšava iskustvo, ali bezbednosna kontrola mora postojati na serveru. Potrebno je definisati očekivani tip, format, dužinu, opseg i obaveznost svakog polja.

Posebnu pažnju zahtevaju:

• HTML i rich-text sadržaj, gde treba dozvoliti samo jasno definisan podskup oznaka;
• SQL, NoSQL i druge upite, koji moraju koristiti odgovarajuće parametrizovanje;
• URL parametre i preusmeravanja, naročito kada se vrednost prosleđuje spolja;
• komande sistema, template-e i izraze koji ne smeju direktno primati korisnički unos;
• upload fajlova: veličina, tip, sadržaj, naziv, skladištenje izvan izvršnog direktorijuma i kontrola preuzimanja.

Zaštita od CSRF napada, XSS-a i drugih čestih obrazaca ne treba da se rešava jednom univerzalnom funkcijom. Mehanizam zavisi od frameworka i načina rada sesija. OWASP Cheat Sheet Series daje praktične smernice za konkretne teme, uključujući output encoding, session management i file upload.

6. Tajne, ključevi i third-party integracije

API ključevi, tokeni, lozinke baze i privatni sertifikati ne pripadaju repozitorijumu, JavaScript bundle-u, screenshotu ili javnom logu. Pre produkcije proverite gde se tajne čuvaju, ko može da ih pročita, kako se menjaju i da li se mogu opozvati. Ako se tajna slučajno objavi, brisanje iz poslednjeg commita nije dovoljno: vrednost treba smatrati kompromitovanom i rotirati je.

Za svaku integraciju zabeležite:

• koji sistem inicira poziv i kojim pravima raspolaže;
• da li se proverava potpis ili autentičnost webhook-a;
• koji podaci se šalju trećoj strani i da li su zaista neophodni;
• šta se dešava kada servis vrati grešku ili kasni;
• kako se ključ opoziva bez potpunog prekida rada.

Minimalne privilegije su korisnije od jednog „master“ ključa koji omogućava sve. Razdvojite razvojne i produkcione kredencijale i proverite da li CI/CD sistem ne prikazuje tajne u outputu builda.

7. Sigurnosna zaglavlja i browser ponašanje

HTTP zaglavlja mogu smanjiti prostor za zloupotrebu, ali moraju biti uvedena prema stvarnim resursima i integracijama. Pre produkcije proverite barem da li je planirano sledeće:

CSP posebno zahteva iteraciju: previše stroga politika može pokvariti analitiku ili plaćanje, a preširoka politika daje lažan osećaj zaštite. Testirajte zaglavlja na stagingu i pratite browser konzolu pre uključivanja restriktivnog režima u produkciji.

8. Zavisnosti, patching i supply-chain rizik

Bezbednost aplikacije zavisi i od paketa, tema, pluginova, base image-a i build alata. Napravite spisak produkcionih zavisnosti i odredite ko prati bezbednosne objave. Ne treba automatski instalirati svaku novu verziju direktno u produkciju, ali ni ostaviti komponente bez vlasnika i plana ažuriranja.

• zaključajte verzije tamo gde je potrebna reproduktivnost builda;
• uklonite neiskorišćene pakete i pluginove;
• proverite poreklo i održavanje kritičnih komponenti;
• pokrenite dependency scan i pregledajte rezultate, umesto da samo sačuvate izveštaj;
• testirajte patch u kontrolisanom okruženju i definišite rollback.

Sigurnost ne sme biti jedini kriterijum release-a. Uticaj na performanse, dostupnost i pristupačnost treba razmatrati zajedno. Na primer, preporuke iz teksta o performance budgetu pomažu da se sigurnosne i tehničke odluke proveravaju kroz merljive razvojne zahteve, umesto da se rešavaju tek nakon objave.

9. Backup, logovi i monitoring

Backup nije potvrđen dok nije testiran restore. Pre produkcije definišite šta se kopira, koliko često, gde se kopije čuvaju, koliko dugo se zadržavaju i ko može da ih vrati. Kopija dostupna kroz isti kompromitovani server nije dovoljna zaštita; potrebno je razmotriti odvajanje, ograničavanje pristupa i zaštitu od brisanja.

Logovi treba da podrže istragu, ali ne smeju da sadrže lozinke, tokene, cele payment podatke ili nepotrebne lične informacije. Beležite prijave, promene privilegija, reset lozinke, administrativne izmene, neuspele webhook provere i neuobičajene greške. Dogovorite ko dobija upozorenje, u kom roku se reaguje i gde se vodi evidencija.

Za svaki važniji incident korisno je imati kratak plan: izolacija pogođenog dela, opoziv ključeva, očuvanje logova, procena podataka, komunikacija sa odgovornim stranama i bezbedan povratak u rad. Pravne obaveze mogu zavisiti od vrste podataka i uloga organizacije, pa ih treba proveriti sa odgovornim pravnim ili compliance savetnikom.

10. Release checklist za poslednji pregled

Pre puštanja produkcije odgovorna osoba treba da može da odgovori na ova pitanja:

1. Da li su inventar podataka, spoljašnjih servisa i privilegija dokumentovani?
2. Da li su debug režim, testni nalozi i nepotrebne rute uklonjeni?
3. Da li HTTPS, kolačići, sesije i autorizacija rade prema očekivanom modelu?
4. Da li su forme, API rute i upload testirani na nevalidne i zlonamerne ulaze?
5. Da li su tajne izvan koda i da li postoji plan rotacije?
6. Da li su zaglavlja proverena sa stvarnim integracijama?
7. Da li su zavisnosti pregledane, a kritične ranjivosti rešene ili prihvaćene uz dokumentovan razlog?
8. Da li backup može da se vrati i da li postoje logovi za važne administrativne događaje?
9. Da li postoji rollback i kontakt osoba za incident nakon objave?

Ovaj pregled ne mora da bude birokratski dokument od više desetina strana. Za mali sajt može biti kratka, potpisana release checklista; za aplikaciju sa nalozima i osetljivim podacima treba je proširiti threat modelom, testovima autorizacije, pregledom infrastrukture i nezavisnim bezbednosnim testiranjem.

Web security je proces koji počinje pre deploy-a

Najvrednija bezbednosna odluka često se donosi pre pisanja koda: jasno definisati podatke, granice pristupa, odgovornosti i način oporavka. Kada se te odluke ugrade u arhitekturu, razvojni tim može da proverava konkretne kontrole kroz kod, konfiguraciju i release pipeline. Ako se security ostavi za poslednji dan, problemi se obično pretvaraju u hitne izmene, odlaganje objave ili prihvatanje rizika bez dovoljno informacija.

Sledeći korak je da ovu listu prilagodite konkretnom sajtu: označite šta je primenljivo, navedite vlasnika svake kontrole i dodajte dokaz da je provera izvršena. Za projekte sa složenijom infrastrukturom povežite bezbednosne zahteve sa arhitekturom, performansama i pristupačnošću — na primer kroz tekst o pristupačnosti koju development tim ugrađuje od početka. Tako web security postaje deo kvaliteta proizvoda, a ne samo stavka pred sam izlazak na produkciju.