# Hogyan véd egy ajánlatkérő űrlap a spam ellen?

URL: https://rootcr.hu/tudastar/urlap-spam-vedelem/
Frissítve: 2026-08-14

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

> **Röviden:** Egy űrlapot nem egy megoldás véd, hanem rétegek sorozata: eredet-ellenőrzés, rejtett csapda-mező, méretkorlát, ember-ellenőrzés és IP-alapú korlátozás. A sorrend számít: elöl az olcsó ellenőrzések állnak, amelyek egy fejléc elolvasásából eldőlnek, hátul a drágák, amelyek külső szolgáltatást hívnak. Így egy támadó nem tud a szervereddel dolgoztatni, és a valódi érdeklődő sem akad fenn.

## 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](/referenciak/pekarunagyker/).

## Gyakori kérdések

### A reCAPTCHA nem elég?

Egy réteg önmagában soha nem elég, és a reCAPTCHA a felhasználót is terheli. A süti nélküli, viselkedés-alapú ellenőrzés ma jobb csere — de az is csak egy réteg az ötből.

### Nem fog fennakadni a valódi érdeklődő?

Az első három réteg számára a valódi látogató láthatatlan: nem kell tennie semmit. A negyedik réteg jó megvalósítás mellett a legtöbb látogatónak egy kattintás vagy annyi sem. Az ötödik réteg csak akkor jelez, ha valaki órán belül sokadszor küld.

### Ez mennyibe kerül?

Ha az űrlap az építés része, akkor semmibe: nálam ez minden [egyedi weboldal](/egyedi-weboldal-keszites/) alapfelszereltsége. Utólag, meglévő rendszerbe építve néhány óra munka.