Vissza a blogra
Alapok Közzétéve: 19.08.2026 8 perc olvasás

Mi védi valójában az űrlapot: CAPTCHA, honeypot, időcsapda, CSRF

A legtöbb kapcsolatfelvételi űrlap egyetlen trükkre hagyatkozik a spam ellen, és sok ilyen trükk csak a legegyszerűbb botokat állítja meg. Mit állít meg az egyes védelmi rétegek mindegyike, mibe kerül, és melyik kombináció észszerű.

A kapcsolatfelvételi űrlapokon érkező spam ritkán származik olyan embertől, aki kézzel gépel. Többnyire szoftverről van szó, amely megkeresi az űrlapokat, kitölt minden mezőt, és elküldi az eredményt – ezerszámra. Többféle védekezés létezik, és ezek nagyon különböző pontokon hatnak. Ha tudja, mit tesz valójában mindegyik, két hibát kerülhet el: a valódi védelem nélküli űrlapot, és az olyan erősen őrzött űrlapot, amelynél a valódi emberek feladják.

A védelmi rétegek összehasonlítása
Réteg és amit megállít
  • Honeypot: egyszerű botok, amelyek minden mezőt kitöltenek
  • Időcsapda: szkriptek, amelyek a betöltés után azonnal küldenek
  • CAPTCHA: a legtöbb általános automatizálás
  • CSRF-token: közvetlenül a végpontra küldött kérések
  • Sebességkorlát: egyetlen forrásból érkező áradat
  • Proof-of-work: olcsó tömeges beküldések, követés és feladványok nélkül
  • Szerveroldali ellenőrzések: minden, ami megkerüli a böngészőt
Amit nem fog meg, vagy amibe kerül
  • A célzott botok kihagyják; ha rosszul van elrejtve, a képernyőolvasók felolvassák
  • Várakozó botok; szerveroldali aláírás nélkül könnyen hamisítható
  • Akadály mindenki számára, akadálymentességi korlátok, gyakran harmadik féltől származik; léteznek megoldó szolgáltatások
  • A botok, amelyek előbb betöltik az oldalt, szintén érvényes tokent kapnak
  • Sok IP-címre szétosztott spam
  • Elszánt, számítási kapacitással rendelkező küldő; JavaScriptet igényel
  • Önmagában semmit – de nélkülük minden más réteg csak dekoráció
Egyetlen réteg sem fed le mindent. Az olcsó, láthatatlan rétegek kiszűrik a tömeget; a nehezebbek a kitartó, célzott spam ellen valók.

Honeypot és időcsapda: láthatatlan szűrők

A honeypot egy extra mező, amelyet az emberek soha nem látnak, például egy CSS-sel elrejtett „website” nevű mező. Az egyszerű botok minden mezőt kitöltenek, így egy kitöltött honeypot automatizálásra utal, és a szerver csendben elvetheti az üzenetet. Az Ön oldalára írt botok, illetve azok, amelyek böngészőként jelenítik meg az oldalt, kihagyják. Rejtse el megfelelően: egy csupán a képernyőn kívülre tolt mezőt a képernyőolvasók felolvashatnak, a Tab billentyűvel elérhető, vagy az automatikus kitöltés kitöltheti. Használja az aria-hidden, a tabindex -1 és az autocomplete off beállítást, valamint egy semleges címkét, amely arra kéri azt, aki odatéved, hogy hagyja üresen.

Az időcsapda rögzíti, mikor küldték ki az űrlapot, és elutasítja az irreálisan gyorsan érkező beküldéseket. Az embereknek néhány másodpercre van szükségük az olvasáshoz és a gépeléshez; sok szkript a másodperc törtrésze alatt küld. Az időbélyeget a szerveren kell ellenőrizni, és védeni kell a manipuláció ellen, például aláírással vagy a munkamenetben tárolva – egy egyszerű rejtett időmezőt a bot egyszerűen átír. Tartsa alacsonyan a küszöböt, mert az automatikus kitöltés a valódi embereket is gyorssá teszi. Az egyszerűen várakozó botok átjutnak: az időcsapda szűrő, nem fal.

CAPTCHA: hatékony, de nem ingyenes

A CAPTCHA annak bizonyítását kéri, hogy nem bot dolgozik – a képes feladványoktól a háttérben futó ellenőrzésekig; elterjedt szolgáltatások a reCAPTCHA, a hCaptcha, a Cloudflare Turnstile és a Friendly Captcha. A legtöbb általános automatizálást megállítja, ezért olyan népszerű. Ám minden látható feladvány olyan akadály, amelynél egyes látogatók feladják, és a legtöbb szolgáltatás harmadik féltől származó szkriptet tölt be, ami adatvédelmi és hozzájárulási kérdéseket vet fel. Egy CAPTCHA ráadásul csak akkor segít, ha helyesen van beállítva: egy nyilvános teszt-webhelykulcs, egy szkript nélküli widget vagy egy token, amelyet a szerver soha nem ellenőriz, védelemnek látszik, de nem az. A formexposed.com ingyenes ellenőrzése kívülről rámutat az ilyen hibákra.

Az akadálymentesség is része ennek az árnak. A képes feladványok kizárják a vakokat és sok gyengénlátót, a hangalapú alternatívák nem segítenek a siketvakoknak, a trükkös logikai feladatok pedig megterhelik a kognitív károsodással élőket. A WCAG 2.2 1.1.1-es sikerességi feltétele szöveges alternatívát ír elő, amely leírja a CAPTCHA célját, valamint különböző érzékszervekhez igazodó alternatív formákat. A háttérben futó ellenőrzések ennek nagy részét elkerülik, de ha gyanússá válnak, a tartalék gyakran ismét egy vizuális feladvány – tesztelje ezt az utat billentyűzettel és képernyőolvasóval.

CSRF-token: védelem a hamisítás ellen, nem a spam ellen

A CSRF-token egy véletlenszerű érték, amelyet a szerver elhelyez az űrlapban, és visszavár. A webhelyek közötti kéréshamisítás ellen tervezték, amikor egy másik weboldal ráveszi a látogató böngészőjét, hogy olyan kérést küldjön, amelyet a látogató soha nem szándékozott. Egy nyilvános kapcsolatfelvételi űrlapon van egy mellékhatása: azokat a botokat, amelyek az oldal betöltése nélkül, közvetlenül az űrlap címére küldenek, elutasítják. Minden bot, amely lekéri az oldalt és visszaküldi a tokent, átjut. A legtöbb keretrendszer és űrlapbővítmény amúgy is tartalmaz CSRF-tokent – hagyja bekapcsolva, de ne számítsa spamvédelemnek.

Aminek a szerveren kell történnie

A csak böngészőben futó ellenőrzések semmit sem védenek
Mindent, ami csak a böngészőben fut – JavaScript-érvényesítést, a honeypotot ellenőrző szkriptet, egy CAPTCHA-tokent, amelyet senki sem ellenőriz –, kihagynak, amint valaki közvetlenül küldi el a kérést. Minden döntés arról, hogy egy üzenetet elfogadnak-e, a szerverre tartozik.
  • Érvényesítsen minden mezőt újra a szerveren: kötelező mezők, hossz, e-mail-formátum, és ne legyen sortörés azokban a mezőkben, amelyek a levél fejlécébe kerülnek.
  • Ellenőrizze a CAPTCHA- és proof-of-work tokeneket minden beküldésnél a kiállító szolgáltatásnál vagy a saját kódjában, és utasítsa el az újra felhasznált tokeneket.
  • Korlátozza a beküldéseket IP-címenként és időablakonként. Ez megállítja az egyetlen forrásból érkező áradatot; a sok címre szétosztott spamhez más rétegek kellenek.
  • Fontolja meg a proof-of-work-öt: küldés előtt a böngésző megold egy kis számítási feladatot. A látogatók nem látnak feladványt, és semmit sem követnek nyomon, a tömeges beküldés viszont drágává válik.

Észszerű kombináció: két-három réteg

  1. 1Kezdje a láthatatlan rétegekkel: egy akadálymentes honeypottal és egy aláírt időcsapdával, mindkettőt a szerveren ellenőrizve.
  2. 2Adjon hozzá IP-címenkénti sebességkorlátot, hogy egyetlen forrás se áraszthassa el az űrlapot.
  3. 3Ha a célzott spam még mindig átjut, adjon hozzá proof-of-work-öt vagy CAPTCHA-t – lehetőleg látható feladvány nélkülit és akadálymentes alternatívával.
  4. 4Tartsa meg a keretrendszere által biztosított CSRF-tokent – ráadásként, nem védekezésként.
  5. 5Tesztelje az eredményt látogatóként – csak billentyűzettel, képernyőolvasóval, telefonon –, és ellenőrizze, hogy a valódi üzenetek továbbra is megérkeznek-e.

Sok oldalon a honeypot, az időcsapda és a sebességkorlát együtt már kiszűri az általános spam nagy részét, látható akadály nélkül; a CAPTCHA a tartalék arra az esetre, ha ez nem elég. WordPressen az ingyenes formexposed bővítmény a Google nélkül egyesíti a honeypotot, az időellenőrzést és a proof-of-work-öt. Hogy lássa, mit mutat az űrlapja kívülről – mely rétegek vannak jelen, hatékonyan van-e beállítva a CAPTCHA –, a formexposed.com ingyenes ellenőrzéséhez csak egy domain kell, fiók nem. A szerverkódját nem látja, így a szerveroldali rész az Ön feladata marad.