A biztonságos űrlapok két pillére: kliens- és szerveroldali validálás
Az interaktív webes alkalmazások gerincét az űrlapok alkotják. Még egy egyszerű bejelentkezési vagy regisztrációs felület is komoly kihívásokat jelenthet, ha nem kezeljük megfelelően a felhasználók által bevitt adatokat. A HTML-űrlapok validálása nem luxus, hanem alapvető biztonsági és felhasználói élménybeli követelmény.
Ebben a cikkben megvizsgáljuk, miért szükséges a validálás mind kliens-, mind szerveroldalon, hogyan valósítható meg a gyakorlatban, és milyen gyakori hibákat érdemes elkerülni.
Miért nem elég csak az egyik oldalon validálni?
A validálás célja kettős:
- Azonnali visszajelzés biztosítása a felhasználó számára a hibás adatok esetén (kliensoldali validálás).
- Az alkalmazás védelme a hibás vagy rosszindulatú adatokkal szemben (szerveroldali validálás).
A kliensoldali validálás gyors és kényelmes, azonban soha nem tekinthető biztonsági intézkedésnek. Egy tapasztalt felhasználó könnyedén kikapcsolhatja a JavaScriptet, módosíthatja a HTML-kódot, vagy közvetlen HTTP-kéréseket küldhet az alkalmazás felé, teljesen megkerülve a böngészőben futó ellenőrzéseket.
Ezért minden kliensoldali ellenőrzést kötelező megismételni a szerveroldalon is.
Kliensoldali validálás: a felhasználó első segítője
A modern HTML5 számos beépített validációs lehetőséget kínál, amelyek jelentősen csökkentik a szükséges JavaScript mennyiségét.
HTML5 beépített attribútumok
A required, minlength, maxlength, type="email", type="url", min és max attribútumok automatikus validálást biztosítanak.
A böngésző megakadályozza az űrlap elküldését, amíg ezek a feltételek nem teljesülnek, és alapértelmezett hibaüzeneteket jelenít meg.
JavaScript alapú finomhangolás
A beépített validáció sok esetben elegendő, de előfordulhat, hogy speciális szabályokat is szeretnénk alkalmazni. Erre szolgál a Constraint Validation API.
const form = document.getElementById('regisztracio'); const jelszoInput = document.getElementById('jelszo'); jelszoInput.addEventListener('input', () => { const ertek = jelszoInput.value; if (ertek.length > 0 && ertek.length < 8) { jelszoInput.setCustomValidity( 'A jelszónak legalább 8 karakter hosszúnak kell lennie.' ); } else { jelszoInput.setCustomValidity(''); } }); form.addEventListener('submit', (event) => { if (!form.checkValidity()) { event.preventDefault(); alert('Kérjük, ellenőrizze a kitöltött adatokat!'); } });Szerveroldali validálás: az utolsó védelmi vonal
A szerveroldali validálás biztosítja az adatok integritását és az alkalmazás biztonságát. Minden adatot ellenőrizni kell, függetlenül attól, hogy korábban kliensoldalon már validáltuk-e.
Az alábbi példa egy egyszerű Node.js és Express alapú megoldást mutat be:
const express = require('express'); const app = express(); app.use(express.urlencoded({ extended: true })); app.use(express.json()); app.post('/regisztracio', (req, res) => { const { email, jelszo, szuletes, weboldal } = req.body; const hibak = []; const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; if (!email || !emailRegex.test(email)) { hibak.push('Érvénytelen e-mail cím.'); } if (!jelszo || jelszo.length < 8) { hibak.push( 'A jelszónak legalább 8 karakter hosszúnak kell lennie.' ); } const szuletesDate = new Date(szuletes); const minDate = new Date('1900-01-01'); const maxDate = new Date(); if ( isNaN(szuletesDate.getTime()) || szuletesDate < minDate || szuletesDate > maxDate ) { hibak.push('Érvénytelen születési dátum.'); } if ( weboldal && !weboldal.startsWith('http://') && !weboldal.startsWith('https://') ) { hibak.push( 'Az URL-nek http:// vagy https:// előtaggal kell kezdődnie.' ); } if (hibak.length > 0) { return res.status(400).json({ sikeres: false, hibak }); } res.json({ sikeres: true, uzenet: 'Sikeres regisztráció!' }); });Biztonsági szempontok: több mint validálás
A validálás önmagában nem elegendő a biztonságos alkalmazás kialakításához.
1. SQL Injection elleni védelem
Mindig használjunk paraméterezett lekérdezéseket vagy ORM-rendszereket.
2. XSS (Cross-Site Scripting) elleni védelem
A felhasználói adatokat megjelenítés előtt megfelelően escape-elni vagy szűrni kell.
3. CSRF (Cross-Site Request Forgery) elleni védelem
Az állapotmódosító műveletekhez mindig használjunk CSRF-tokeneket.
4. Fájlfeltöltések ellenőrzése
Ne csak a fájl kiterjesztését ellenőrizzük, hanem a MIME-típust és lehetőség szerint a fájl tényleges tartalmát is.
Gyakori hibák és azok elkerülése
1. Csak kliensoldali validálás használata
Ez az egyik legveszélyesebb hiba. A kliensoldali ellenőrzések könnyen megkerülhetők.
2. Túl bonyolult reguláris kifejezések
Ne írjunk nehezen karbantartható regexeket, ha létezik megbízható könyvtár vagy beépített megoldás.
Népszerű könyvtárak:
- validator.js
- Joi
- Yup
- Zod
3. Nem megfelelő hibaüzenetek
A „Hibás bemenet” helyett adjunk pontos visszajelzést:
- „Az e-mail cím formátuma érvénytelen.”
- „A jelszónak legalább egy nagybetűt kell tartalmaznia.”
4. Bizalmas információk kiszivárogtatása
Ne áruljuk el, hogy egy adott felhasználónév létezik-e a rendszerben.
Rossz példa:
- „A felhasználónév létezik, de a jelszó hibás.”
Jó példa:
- „Hibás felhasználónév vagy jelszó.”
5. A validálás és a sanitizálás összekeverése
A validálás ellenőrzi az adat helyességét.
A sanitizálás megtisztítja az adatot a veszélyes vagy nem kívánt tartalmaktól.
Mindkettőre szükség van.
Összefoglalás
Az űrlapvalidálás egy kétlépcsős folyamat, amelynek mindkét része nélkülözhetetlen.
A kliensoldali validálás javítja a felhasználói élményt az azonnali visszajelzések segítségével, míg a szerveroldali validálás védi az alkalmazást és az adatokat a hibás vagy rosszindulatú bemenetektől.
Fontos szem előtt tartani, hogy a kliensoldali validálás kényelmi funkció, míg a szerveroldali validálás biztonsági kötelezettség.
A gyakorlatban érdemes a validációs szabályokat központilag kezelni, például külön validációs osztályok vagy függvények segítségével. Ez csökkenti a kódismétlést, növeli a karbantarthatóságot, és biztosítja a konzisztens működést az alkalmazás minden végpontján.
A megfelelő validálási stratégia nemcsak a hibás adatok ellen véd, hanem hozzájárul az alkalmazás megbízhatóságához, biztonságához és a felhasználók bizalmának növeléséhez is.