# pekarunagyker.hu — ajánlatkérő öt védelmi réteggel

URL: https://rootcr.hu/referenciak/pekarunagyker/
Frissítve: 2026-08-14

# pekarunagyker.hu — egy űrlap, amit a botok nem tudnak megenni

> **Röviden:** Egy nagykereskedelmi ajánlatkérő űrlapon öt védelmi réteg fut egymás után: a kérés csak a saját oldalról érkezhet, a rejtett csapda-mező kiszűri az automata kitöltőt, a túl nagy törzs el sem éri az alkalmazást, lefut az ember-ellenőrzés, végül IP-címenként korlátozott a beküldések száma. Mindegyik réteg szerveroldali kód, nem egy bővítmény ígérete — és a megkeresés előbb kerül lemezre, csak utána megy a levél.

## A feladat

Nagykereskedelmi ajánlatkérésnél a beérkező üzenet pénzt ér: minden egyes sor egy potenciális vevő. Ugyanez a beviteli pont viszont a legkedveltebb célpont is — az automata kitöltők óránként próbálkoznak. Két rossz kimenet van: a spam elönti a postafiókot (és a valódi megkeresés elvész benne), vagy a védelem annyira szigorú, hogy a valódi érdeklődő is fennakad.

## A megoldás: öt réteg, sorrendben

1. **Eredet-ellenőrzés.** A beküldés csak a saját oldalról érkezhet. Ami máshonnan jön, azt a szerver már az adatok kiolvasása előtt elutasítja.
2. **Csapda-mező.** Egy rejtett mező, amit ember sosem lát és sosem tölt ki. Az automata kitöltő viszont minden mezőt kitölt — és ezzel leleplezi magát. A válasz szándékosan „sikeres”, hogy a bot ne tanuljon a hibából.
3. **Méretkorlát.** A túl nagy kérés-törzs el sem éri az alkalmazást: a kiszolgáló szintjén elakad. Ez az a réteg, ami a legolcsóbban véd a terheléses próbálkozás ellen.
4. **Ember-ellenőrzés.** Süti nélküli, adatvédelmi szempontból tiszta ellenőrzés, ami a látogatót nem terheli képválogatással.
5. **IP-korlát.** Címenként korlátozott számú beküldés óránként. Ez nem a botok fő szűrője, hanem a maradék elleni védelem — és a költséges műveletek elé kerül, hogy egy támadó ne tudjon rajtuk keresztül munkát végeztetni a szerverrel.

## Ami az űrlap után történik

A megkeresés **először lemezre kerül, és csak utána megy a levél.** Ez a sorrend szándékos: ha a levélküldő szolgáltatás kiesik, az érdeklődő akkor sem vész el. Ha a levél mégsem megy ki, arról a napló azonnal árulkodik.

A kimenő értesítés hitelesített feladóval megy (SPF és DKIM), válaszcímként pedig az érdeklődő címe szerepel — így a válasz egy kattintás, nem másolgatás.

## A kiszolgálás oldala

Az űrlapot fogadó szolgáltatás önálló, korlátozott jogú folyamatként fut: nem lát a saját könyvtárán kívülre, nem tud jogot emelni, nem tud a rendszer többi részéhez nyúlni, és memória- és folyamatkorlát alatt dolgozik. Ha egy sebezhetőség mégis lenne benne, a kárt ez a keret határolja be.

## Ellenőrizd magad

- [pekarunagyker.hu](https://pekarunagyker.hu/) — az élő oldal; az ajánlatkérő űrlap kipróbálható.
- Küldj el egy üres űrlapot: azonnal látszik, mit mond a rendszer, és hogy a hibaüzenet mennyit árul el (szándékosan keveset).
- [PageSpeed Insights](https://pagespeed.web.dev/) — sebességmérés a Google saját műszerével.

## Mi tanulható belőle?

Hogy az űrlapvédelem nem egy kapcsoló, hanem sorrend. A rétegek olcsótól a drágáig épülnek egymásra: előbb az, ami egy fejléc olvasásából eldől, utoljára az, ami külső szolgáltatás hívását igényli. Ez a sorrend dönti el, hogy egy támadó tud-e munkát végeztetni a szervereddel.

Ha neked is űrlapon jön a bevétel: [egyedi weboldal készítés](/egyedi-weboldal-keszites/). A védelmi rétegek részletes bontása külön írásban: [hogyan véd egy ajánlatkérő űrlap a spam ellen](/tudastar/urlap-spam-vedelem/).