Sve ĆĄto provjeravaĆĄ na client strani, provjeravaĆĄ samo da popraviĆĄ user experienceâŠtako da kaĆŸeĆĄ odmah korisniku ako neko polje nije pravilno ispunjenoâŠitd.
No tu ne stvaraĆĄ nikakvu sigurnost jer imaĆĄ nebrojeno naÄina da korisnik poĆĄalje na server ono ĆĄto on ĆŸeli poslati.
Tako da na serveru moraĆĄ provjeravati polja u svrhu vlastite sigurnostiâŠda ne dobijeĆĄ nekakav SQL injection koji ti pobriĆĄe bazu podatakaâŠitd.
No jedna stvar, korisnik koji te ĆŸeli ânapastiâ âŠon nema niĆĄta od toga ako u formu koju si ograniÄio na 5 slova, poĆĄalje input od 7 slova. (To je samo njegov bed ĆĄto Äe mu kasnije faliti ta dva slova, ili Äe mu biti viĆĄak, âŠili koje veÄ kontradiktornosti Äe sam sebi time stvoriti) Tvoj code u startu ne smije biti osjetljiv na takve âsitniceâ.
ZnaÄi provjera od napada ne treba kontorlirati svaku stavku koju si stvorio radi user experienca, treba samo kontrolirati opasne inpute koji ti mogu naĆĄkoditi.
Ako u nekom inputu 7 karaktera umjeto 5 zaista moĆŸe naĆĄkoditi tvome code-u, onda moraĆĄ kontrolirati dodatno i tu stavku za neki x inputâŠtj. limitirati na serveru upis od 5 karaktera.
Opasni inputi ti se uglavnom veĆŸu za SQL injectionâŠili da ti netko prosljedi nekakav javascript code koji Äe se aktivirati tek kad se ispiĆĄe na otvaranju stranice kao komentar npr.
No za takve stvari ne moraĆĄ smiĆĄljati posebnu kontrolu kod svakog upisa u bazuâŠdovoljno je imati jednu kontrolnu toÄku i sve ĆĄto ti se upisuje u bazu provrtiĆĄ kroz tu kontrolnu toÄku.
E sad, koliko ima sigurnosnih problema koji bi se mogli upisati u bazu osim ovog dvoje ĆĄto sam gore spomenuoâŠto nisam siguran. Lopova uvijek biloâŠuvijek Äe biti. Sa razvojem weba se i granica sigurnosti uvijek pomiÄeâŠ