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.