Hogyan véd egy ajánlatkérő űrlap a spam ellen? Az öt réteg

Miért nem elég egyetlen megoldás?

Mert a támadók sem egyfélék. Az egyszerű kitöltőrobot minden mezőt kitölt és elküld — ezt egy rejtett mező kifogja. A célzott szkript már utánozza a böngészőt — ezt csak ember-ellenőrzés fogja meg. A tömeges próbálkozás pedig nem is a tartalomról szól, hanem arról, hogy a szerveredet lefoglalja.

Egy megoldás mindig csak egy támadástípus ellen véd. Amit építeni kell, az nem fal, hanem szűrősor.

Az öt réteg, sorrendben

1. Eredet-ellenőrzés

A böngésző minden beküldésnél elárulja, melyik oldalról indult a kérés. Ha nem a saját oldaladról, a szerver elutasítja — még mielőtt bármit kiolvasna az adatokból.

Ára: egy fejléc összehasonlítása. Gyakorlatilag ingyen. Mit fog meg: a máshonnan, közvetlenül a végpontra irányuló beküldést.

2. Csapda-mező (honeypot)

Egy rejtett mező, amit ember sosem lát és sosem tölt ki — a böngésző elrejti a képernyőről, a billentyűzetes navigációból is ki van véve. Az automata kitöltő viszont a HTML-t olvassa, nem a képernyőt, ezért kitölti.

Egy fontos részlet: ha a csapda bejelez, a válasz legyen „sikeres”. Ha hibát írsz vissza, a bot fejlesztője megtudja, mi buktatta le, és legközelebb kikerüli.

Ára: egy mező vizsgálata. Ingyen. Mit fog meg: a tömeges kitöltőrobotok nagy részét.

3. Méretkorlát

A túl nagy kérés-törzs el se érje az alkalmazást: a kiszolgáló szintjén akadjon el. Ez nem a spam ellen véd elsősorban, hanem az ellen, hogy valaki a memóriádat és a sávszélességedet foglalja le.

Ára: egy beállítás a kiszolgálón. Mit fog meg: a terheléses próbálkozást és a hibás kliensek okozta pazarlást.

4. Ember-ellenőrzés

Itt jön a kép a képbe — vagy pontosabban: ma már nem kell képválogatás. A modern megoldások (például a Cloudflare Turnstile) a böngésző viselkedéséből döntenek, süti nélkül, a látogató zaklatása nélkül. Ez a reCAPTCHA legfontosabb alternatívája, és adatvédelmi szempontból is tisztább.

Ára: egy hálózati hívás egy külső szolgáltatás felé, időkorláttal. Ez a legdrágább lépés — ezért van hátul. Mit fog meg: a böngészőt utánzó, célzott szkripteket.

5. IP-alapú korlátozás

Címenként korlátozott számú beküldés adott időablakban. Nem a botok fő szűrője, hanem a maradék elleni védelem, és egyben a költséges lépések védelme.

Ára: memóriában tartott számláló. Mit fog meg: az ismétlődő próbálkozást ugyanarról a címről.

Miért számít a sorrend?

Mert minden ellenőrzésnek ára van, és a támadó pont ezt akarja megfizettetni veled. Ha az ember-ellenőrzés (külső hívás) előbb fut, mint az IP-korlát, akkor bárki, aki másodpercenként küld egy kérést, kikényszerít másodpercenként egy kimenő hálózati hívást a szerveredről. A védelem lesz a terhelés forrása.

A helyes sorrend tehát: olcsó ellenőrzések elöl, drágák hátul, és a számláló még a drágák előtt. Ez a különbség az „öt réteget használok” és az „öt réteget jól használok” között.

Amit még érdemes megcsinálni

• Előbb mentés, aztán levél. A beérkezett megkeresés kerüljön lemezre, és csak utána menjen az értesítő levél. Ha a levélküldő szolgáltatás kiesik, az érdeklődő akkor sem vész el.
• Riasztás a néma hibára. Ha a mentés sikerült, de a levél nem ment ki, arról azonnal tudni kell. A legdrágább hiba az, amiről senki nem szól.
• Visszaigazoló levél az érdeklődőnek. Nem udvariasság: ez zárja le a bizonytalanságot, hogy „vajon megérkezett-e”.
• Megőrzési idő. A beérkezett megkeresés személyes adat. Legyen határideje, és teljen is le magától.
• Naplózás jelszó és süti nélkül. Ami nem kell, azt ne is tárold.

Így néz ki mindez élesben: pekarunagyker.hu esettanulmány.

Gyakori kérdések

Frissítve: 2026. szeptember 11.