2026.08.22.
Weboldal fejlesztés és SEO

Biztonságos űrlapok készítése CSRF tokenekkel

Temesvári László

A CSRF védelem: Miért fontos, és hogyan építsd be webes űrlapjaidba?

Bevezetés: A láthatatlan támadás

Gondolj egy tipikus webes űrlapra: bejelentkezés, regisztráció, adatbeküldés. Minden nap használjuk, és ártalmatlannak tűnik. De képzeld el ezt: egy felhasználó belép a banki fiókjába, majd egy másik fülön meglátogat egy feltűnően ártalmatlan blogot. Az oldal azonban tartalmaz egy rejtett, automatikusan beküldődő űrlapot, amely – a felhasználó tudta nélkül – utalást kezdeményez a saját bankjából. Ez a Cross-Site Request Forgery (CSRF) támadás lényege: kihasználja, hogy a böngésződ automatikusan hozzáfűzi a munkamenet adataidat (pl. a sütidet) minden, az adott oldal felé indított kéréshez.

Kisvállalkozó vagy céges döntéshozóként ez nem csupán egy technikai szakkifejezés. Azt jelenti, hogy egy feltörekvő WordPress weboldalad, amelyet épp most fejlesztettek, vagy egy komplex ügyfélportálod biztonsági réseket rejthet, amit kihasználva ügyfeleid adatait vagy akár pénzügyi tranzakcióit manipulálhatják. A CSRF védelem nem opcionális „extra”, hanem alapvető biztonsági gyakorlat minden olyan weboldal készítésénél, ahol felhasználói interakció történik.

A CSRF token: A digitális pecsét

A megoldás a CSRF token (vagy „vezérjel”) alkalmazása. Ez egy egyedi, kiszámíthatatlan, munkamenetenként változó kód, amit a szerver generál és az űrlaphoz csatol. Amikor a felhasználó beküldi az űrlapot, a token is visszakerül a szerverre. A szerver ellenőrzi: „Ez a token, amit én adtam neked, egyezik a visszakapottal?” Ha nem, a kérést elutasítja. Mivel egy rosszindulatú, harmadik oldalon lévő űrlap nem fér hozzá ehhez a tokenhez (a böngésző biztonsági szabályai, az ún. Same-Origin Policy megakadályozza ezt), a támadás meghiúsul.

Hogyan működik ez a gyakorlatban?

Képzeljük el egy egyszerű PHP backend-et, ami egy WordPress testreszabás vagy egy hagyományos webfejlesztési projekt része lehet. A szerver oldalon generálunk egy tokent, és elrejtjük az űrlapban.

Backend (PHP) – Token generálása és ellenőrzése:

    
    
    <button type="submit">Küldés</button>

A fenti példa a hash_equals() függvényt használja, amely időálló összehasonlítást végez, hogy ne lehessen időzítési támadásokkal kikövetkeztetni a tokent.

Frontend: A token integrálása dinamikusabb környezetben

A modern weboldal készítés során gyakran használunk JavaScriptet (pl. jQuery) az űrlapok aszinkron beküldéséhez. Itt is ugyanaz az elv érvényesül: meg kell szereznünk a tokent a szervertől, és hozzá kell csatolnunk a kéréshez. Bootstrap-es felületen dolgozunk, de a lényeg a logikában van.

Frontend (jQuery + Bootstrap integrációval):

// JavaScript / jQuery
$(document).ready(function() {
    // Tegyük fel, hogy a tokent a szerver a HTML-be ágyazza egy meta tag-ként
    var csrfToken = $('meta[name="csrf-token"]').attr('content');

    $('#myForm').on('submit', function(e) {
        e.preventDefault(); // Megállítjuk a hagyományos beküldést

        var formData = $(this).serializeArray();
        // Hozzáadjuk a CSRF tokent a küldendő adatokhoz
        formData.push({name: 'csrf_token', value: csrfToken});

        $.ajax({
            url: $(this).attr('action'),
            type: 'POST',
            data: $.param(formData),
            success: function(response) {
                // Sikeres beküldés kezelése
                $('#resultAlert').removeClass('d-none alert-danger').addClass('alert-success').text('Sikeres mentés!');
            },
            error: function(xhr) {
                // Hiba kezelése (pl. érvénytelen token)
                $('#resultAlert').removeClass('d-none alert-success').addClass('alert-danger').text('Hiba történt. Kérjük, frissítsd az oldalt.');
            }
        });
    });
});
/* SCSS / CSS - A visszajelzés stílusozása Bootstrap alapokon */
#resultAlert {
    transition: all 0.3s ease-in-out;
    // A Bootstrap .alert osztályait kiegészítjük saját stílusokkal
    &.alert-success {
        border-left: 5px solid #28a745;
    }
    &.alert-danger {
        border-left: 5px solid #dc3545;
    }
}

Gyakori buktatók és „Ne” tegyük” lista

1. Token a statikus HTML-ben: Soha ne írd bele a tokent statikus HTML fájlba. Mindig a szerver (PHP, stb.) dinamikusan generálja. 2. Token újrahasználata kritikus műveleteknél: Különösen fontos műveleteknél (pl. jelszóváltoztatás, email cím módosítás) érdemes egy alkalommal érvényes, „single-use” tokent használni, vagy megerősítő lépést kérni. 3. GET kérések módosításra: SOHA ne valósíts meg adatmódosító műveletet (törlés, frissítés) GET kéréssel. A CSRF token védelme csak POST (vagy PUT, DELETE) kérésekre vonatkozik. 4. Fejlesztői környezet kihagyása: A védelmet a fejlesztés legkorábbi szakaszában építsd be, ne csak éles környezetben. Ez része a „security by design” (biztonság tervezéssel) szemléletnek. 5. Csak a formokra koncentrálás: A CSRF támadás nem csak klasszikus űrlapokon keresztül érkezhet. Aszinkron (AJAX) kérések is sebezhetőek lehetnek, ezért ott is alkalmazni kell a védelem (mint a fenti jQuery példában).

Összegzés: A biztonság alapköve

A CSRF védelem megvalósítása nem csillagászati összegű befektetés, hanem tudatos tervezés és beépítés kérdése. Legyen szó WordPress weboldal készítésről, ahol pluginekkel (pl. a beépített nemcésszel) könnyen kezelhető, vagy egy teljesen egyedi webfejlesztési projekt backendjéről, ahol a fenti mintákat implementáljuk – a lényeg, hogy legyen.

Kisvállalkozóként ezzel véded a vállalkozásod hírnevét és az ügyfeleid adatait. Céges döntéshozóként pedig nem csak technikai kötelezettség teljesítéséről van szó, hanem kockázatcsökkentésről és a digitális aktiváid integritásának védelméről. Egy megbízható webfejlesztő partnermindig felhozza ezt a témát – ha nem teszi, érdemes újragondolni a partnerkapcsolatot. A biztonság nem egy funkció, hanem a siker alapja.

A weboldalon megjelenő szöveges és vizuális tartalmak előállításához mesterséges intelligenciát (AI) használunk.

Kapcsolódó cikkek