Ne törjék fel a weboldalad.

Te egy tapasztalt alkalmazásbiztonsági szakértő vagy (OWASP Top 10, OWASP ASVS, webes infrastruktúra). Végezz biztonsági átvilágítást a weboldalamon: a kód ebben a mappában van, az élő oldal címe: [IDE ÍRD AZ OLDAL CÍMÉT].

## SZABÁLYOK
1. **Először csak vizsgálj, ne módosíts semmit.** Javítani csak a jelentés után és az én jóváhagyásommal lehet.
2. **Az élő oldalt csak kíméletesen vizsgáld:** olvasó jellegű kérésekkel (pl. `curl -sI`, `curl -s`). Nincs brute force, terheléses teszt, sebezhetőség-szkenner, sem valódi támadó payload éles adatokon.
3. **Titkos adatot soha ne írj ki teljes egészében** (jelszó, API-kulcs, token, privát kulcs), csak a típusát, a helyét és az első 4 karakterét.
4. **Ne commitolj és ne pusholj semmit.** A változtatásokat a munkakönyvtárban hagyd, hogy átnézhessem.
5. **Minden megállapításhoz kell bizonyíték:** fájl és sor, parancs és kimenet, vagy válaszfejléc. Amit nem tudtál ellenőrizni, azt „nem ellenőrizhető” jelöléssel írd be, és mondd meg, hogyan nézhetem meg én.

## 0. LÉPÉS · FELDERÍTÉS (ez kerüljön a jelentés elejére)
- **Technológia:** statikus HTML, React/Vite, Next.js, WordPress vagy más; build-folyamat; a kimeneti mappa (dist/out/.next).
- **Tárhely és üzemeltetés:** hosting (pl. Vercel, Netlify, saját szerver), deploy módja, előnézeti környezetek, domain- és DNS-szolgáltató.
- **Backend-részek:** API-útvonalak, szerverless függvények, Google Apps Script, adatbázis (Supabase, Firebase, MySQL), bejelentkezés, fájlfeltöltés.
- **Harmadik felek:** analitika, Pixel, chat, térkép, videó, betűtípusok, CDN-ek, űrlap- és e-mail-szolgáltató.
- **Adatok:** milyen személyes adat jön be (űrlap, fotó, e-mail), és hová kerül (e-mail, táblázat, adatbázis).
- **Alkalmazhatóság:** a fenti alapján jelöld, mely fejezetek relevánsak. A nem relevánsakat egy sorban zárd le.

## ELLENŐRZŐ LISTA

### A · Szállítás, TLS és domain
1. Minden HTTP-kérés 301-gyel egyetlen kanonikus HTTPS-címre irányít-e (http→https, www vagy nem www)? Nincs-e vegyes tartalom (http-s kép, script vagy iframe)?
2. A tanúsítvány érvényes-e, automatikusan megújul-e, és csak TLS 1.2 vagy újabb protokollt fogad-e el?
3. **Domain:**
   - van-e regisztrátori zár (transfer lock) és automatikus megújítás, és mikor jár le a domain;
   - be van-e kapcsolva a kétlépcsős belépés a regisztrátornál és a DNS-szolgáltatónál;
   - van-e CAA rekord.
4. **Lógó DNS-rekordok:** nincs-e olyan CNAME vagy aldomain, ami megszűnt szolgáltatásra mutat (ezzel az aldomain átvehető)?
5. **E-mail-hamisítás elleni védelem:** van-e SPF, DKIM és DMARC rekord a domainen (legalább `p=quarantine`)? Ha nincs, bárki küldhet levelet a cég nevében.

### B · HTTP biztonsági fejlécek (az élő oldal tényleges válaszai alapján)
6. `Strict-Transport-Security: max-age=31536000; includeSubDomains`. A `preload`-ot csak akkor javasold, ha minden aldomain HTTPS-en fut, és jelezd, hogy nehéz visszavonni.
7. **Content-Security-Policy, az oldal valódi forrásaihoz szabva:**
   - legyen benne `default-src 'self'`, `object-src 'none'`, `base-uri 'self'`, `form-action` és `frame-ancestors`;
   - kerülendő az `unsafe-inline` és az `unsafe-eval` (helyette nonce vagy hash);
   - **először `Content-Security-Policy-Report-Only` módban vezesd be**, hogy ne törjön el semmi.
8. **További fejlécek:**
   - `X-Content-Type-Options: nosniff`;
   - `Referrer-Policy: strict-origin-when-cross-origin`;
   - `Permissions-Policy`, a nem használt funkciók tiltásával (camera, microphone, geolocation stb.);
   - `Cross-Origin-Opener-Policy: same-origin`;
   - `X-Frame-Options: DENY` vagy `SAMEORIGIN`, a régi böngészők miatt a `frame-ancestors` mellett.
9. **Információszivárgás:** ne legyen `X-Powered-By` vagy verziószámos `Server` fejléc. Az elavult `X-XSS-Protection`-t NE add hozzá (ha mégis szerepel, legyen `0`).
10. **Hol állítsuk be:** a fejléceket a megfelelő helyen kell beállítani (pl. `vercel.json`, `_headers`, `.htaccess`, nginx, Next.js `headers()`). Ellenőrizd, hogy minden útvonalra érvényesek-e, a 404-es oldalra és a statikus fájlokra is.

### C · Titkok és kiszivárgó fájlok
11. **Titkos adatok keresése** a teljes git-történetben (`git log -p`, minden ágon), a kódban, a konfigurációban és **a buildelt kimenetben** is: API-kulcsok, tokenek, jelszavak, privát kulcsok, Apps Script- és webhook-URL-ek, adatbázis-kapcsolati szövegek.
    - Ami valaha bekerült a gitbe, az **kompromittáltnak számít**: a kulcsot cserélni kell, a történetből törlés önmagában nem elég.
12. **Környezeti változók:**
    - a böngészőbe csak a valóban nyilvános változók kerüljenek (`VITE_`, `NEXT_PUBLIC_`, `PUBLIC_` előtag);
    - a `.env*` fájlok legyenek a `.gitignore`-ban;
    - a titkos kulcsok csak szerveroldalon legyenek.
13. **Kívülről elérhető érzékeny fájlok** (csak `curl -sI` státuszkóddal ellenőrizd):
    - `/.env`, `/.git/config`, `/.DS_Store`;
    - mentések (`*.zip`, `*.sql`, `*.bak`), logok, `phpinfo`;
    - régi teszt- és demóoldalak;
    - **production source map-ek** (`*.js.map`), ezekből a teljes forráskód visszafejthető.
14. **Könyvtárlistázás:** ki van-e kapcsolva? A `robots.txt` nem árul-e el rejtett admin- vagy tesztútvonalat?
15. **Előnézeti és staging környezetek:** nyilvánosak-e (pl. a Vercel preview deploymentek)? Ha igen, kapcsold be rájuk a védelmet, vagy tedd őket noindexre.

### D · Függőségek és ellátási lánc
16. **Ismert sérülékenységek:** `npm audit` (vagy a csomagkezelőnek megfelelő eszköz). Csoportosítsd őket:
    - éles futásidejű csomag vs. csak fejlesztői csomag;
    - valóban elérhető kódút vs. elméleti kockázat.

    Csak az elsőkre javasolj azonnali frissítést, törő verzióváltásnál jelezd a kockázatot.
17. **Csomagkezelés:**
    - a lockfile commitolva van-e, és CI/deploy alatt `npm ci` fut-e;
    - nincsenek-e nem használt, elhagyott vagy elgépelt nevű (typosquatting) csomagok;
    - van-e gyanús `postinstall` script.
18. **Külső scriptek:**
    - csak a szükségesek maradjanak;
    - fix verziójú CDN-fájlokra kerüljön SRI (`integrity` + `crossorigin`);
    - ahol az SRI nem lehetséges (pl. gtag, Pixel), ott a CSP szűkítse a forrást.
19. **CMS esetén (pl. WordPress):**
    - mag, bővítmények és sablon naprakész-e, nincs-e elhagyott bővítmény;
    - `DISALLOW_FILE_EDIT` bekapcsolva;
    - XML-RPC tiltva, ha nem kell;
    - a felhasználónevek ne legyenek kiolvashatók (`/?author=1`, REST `/wp/v2/users`);
    - a `debug.log` ne legyen elérhető;
    - az admin felület védett legyen (2FA, belépési korlát).

### E · Kliensoldali kód (XSS és társai)
20. **Veszélyes kódhelyek:** keresd meg a `innerHTML`, `outerHTML`, `insertAdjacentHTML`, `dangerouslySetInnerHTML`, `document.write`, `eval`, `new Function` és `setTimeout(string)` előfordulásait.
    - Ha ide URL-paraméterből, űrlapból, API-ból vagy táblázatból érkező adat jut, az XSS.
    - Ilyenkor szövegként kell beszúrni (`textContent`), vagy megbízható tisztítóval (DOMPurify).
21. **Felhasználói adatból képzett URL-ek:** `href`, `src`, `window.location`. Nem jöhet-e át `javascript:` séma? Nincs-e nyitott átirányítás (`?redirect=`, `?next=`)?
22. **Egyéb kliensoldali pontok:**
    - a `postMessage` fogadók ellenőrzik-e az `event.origin`-t;
    - a külső `target="_blank"` linkeken van-e `rel="noopener noreferrer"`;
    - a `localStorage` nem tárol-e tokent vagy személyes adatot.
23. **Beágyazások:** az iframe-ek (térkép, videó, foglalás) kapjanak minimális jogot (`sandbox`, ahol lehet; `allow` csak a szükséges funkciókra), és csak megbízható forrásból töltődjenek.

### F · Űrlapok és beérkező adatok
24. **Szerveroldali ellenőrzés:** minden beérkező adat a szerveren (Apps Script, API, függvény) is ellenőrizve legyen, séma szerint:
    - típus, hossz, formátum és engedélyezett értékek;
    - az ismeretlen mezők eldobva.

    A böngészőoldali ellenőrzés nem védelem.
25. **Spam és visszaélés ellen:**
    - honeypot mező és időcsapda;
    - szükség esetén Cloudflare Turnstile vagy reCAPTCHA, **szerveroldali tokenellenőrzéssel**;
    - IP- vagy munkamenet-alapú korlátozás (rate limit).
26. **E-mail-küldés:**
    - a felhasználói adat ne kerülhessen fejlécbe (header injection: sortörés a név vagy a tárgy mezőben);
    - a válaszcím (Reply-To) ellenőrzött legyen;
    - a levél HTML-jébe kerülő adat legyen escape-elve.
27. **Táblázatba írt adat (Google Sheets, CSV export):** a `=`, `+`, `-`, `@`, TAB vagy CR karakterrel kezdődő értékek formulaként futhatnak le (formula injection). Ezeket semlegesíteni kell, pl. egy előtag aposztróffal.
28. **Fájlfeltöltés:**
    - típus ellenőrzése tartalom alapján (nem csak kiterjesztés);
    - méretkorlát;
    - új, véletlen fájlnév;
    - tárolás a webgyökéren kívül vagy privát tárolóban, futtatás nélkül;
    - képeknél az EXIF-adatok (GPS-hely) eltávolítása.
29. **Hibaüzenetek:** a beküldés utáni hibaüzenet ne áruljon el belső részletet (stack trace, elérési út, SQL).

### G · Google Apps Script (ha van)
30. **Webalkalmazás-telepítés:** kinek a nevében fut, és ki férhet hozzá? Az „Anyone” hozzáférésnél **minden** bemenetet ellenőrizni kell a `doPost`/`doGet`-ben.
    - Ellenőrizd a CacheService-alapú rate limitet és a `LockService`-t a párhuzamos írásokhoz.
31. **Táblázat- és Drive-megosztás:** a táblázat és a Drive-mappák ne legyenek „bárki, akinek megvan a link” megosztásúak.
    - Az Apps Script-URL nem titok; a védelem a bemeneti ellenőrzésen múlik, nem az URL rejtettségén.
32. **Hatókörök és titkok:**
    - a szükséges OAuth-hatókörök minimálisak-e (pl. `spreadsheets.currentonly` a teljes Drive helyett);
    - a kulcsok a Script Properties-ben vannak-e, nem a kódban.

### H · Szerveroldal, API és hitelesítés (ha van)
33. **Hitelesítés:**
    - jelszavak argon2id vagy bcrypt (cost ≥ 12) hash-sel;
    - munkamenet-süti `HttpOnly; Secure; SameSite=Lax`;
    - munkamenet-azonosító cseréje belépéskor, érvénytelenítése kilépéskor;
    - lejárat;
    - adminoknak 2FA.
34. **Fiókvédelem:**
    - belépési és jelszó-visszaállítási próbálkozások korlátozása;
    - ne lehessen felhasználókat kideríteni („nincs ilyen e-mail” típusú üzenet);
    - a visszaállító token egyszer használható és rövid életű legyen.
35. **Jogosultság (IDOR / BOLA):** minden végpont a szerveren ellenőrzi-e, hogy az adott felhasználó hozzáférhet-e az adott rekordhoz? Egy azonosító átírásával nem lehet-e más adatát lekérni?
    - Az admin útvonalakat a szerver is védi-e, nem csak a felület rejti el?
36. **API-végpontok:**
    - CSRF-védelem a sütis, állapotot módosító kéréseknél;
    - a CORS ne legyen `*` és ne tükrözze vissza tetszőleges `Origin`-t, ha hitelesített adat jön vissza;
    - csak a szükséges HTTP-metódusok legyenek engedélyezve.
37. **SSRF:** ha a szerver felhasználó által megadott URL-t tölt le, az ne érhessen el belső címeket (pl. `169.254.169.254`, `localhost`).
38. **Adatbázis:**
    - csak paraméterezett lekérdezések, nincs szövegösszefűzéses SQL;
    - az adatbázis-felhasználónak minimális joga van;
    - az adatbázis nem érhető el közvetlenül az internetről.
    - **Supabase:** minden táblán be van-e kapcsolva a Row Level Security, és a policy-k tényleg szűrnek-e? Az `anon` kulcs csak RLS mellett lehet nyilvános, a `service_role` kulcs soha.
    - **Firebase:** a biztonsági szabályok nem `allow read, write: if true`-k-e?
39. **Élesítési beállítások:**
    - debug és fejlesztői mód kikapcsolva;
    - a részletes hibák csak a logba mennek;
    - a logokban nincs jelszó, token vagy fölösleges személyes adat.

### I · Adatvédelmi technikai pontok (a biztonsággal átfedő részek)
40. **Sütik és tárolók listája:** sorold fel az összes sütit, `localStorage`- és `sessionStorage`-bejegyzést, amit az oldal, **a tárhely vagy a weboldalkészítő platform** beállít: név, élettartam, cél, első vagy harmadik fél.
    - A nem feltétlenül szükségesek (analitika, Pixel, látogatóazonosító) csak hozzájárulás után jelenhetnek meg.
    - Ellenőrizd, hogy az elutasítás tényleg megakadályozza-e a betöltésüket.
41. **Hozzájárulás előtti adatküldés harmadik félnek:**
    - Google Fonts a Google szerveréről (javaslat: saját tárhelyre tenni);
    - YouTube (`youtube-nocookie.com`, kattintásra betöltés);
    - Google Maps (kattintásra betöltés);
    - chat- és egyéb widgetek.
42. **Az adatkezelési tájékoztató és a valóság egyezése:** a tájékoztatóban felsorolt adatfeldolgozók (tárhely, levelezés, űrlap, táblázat, analitika) megegyeznek-e azzal, amit a kódban és a hálózati kérésekben ténylegesen látsz?

### J · Üzemeltetés és helyreállítás
43. **Fiókok kétlépcsős védelme:** be van-e kapcsolva a 2FA minden kritikus fiókon (tárhely, domain, DNS, git, Google, e-mail, CMS)? A helyreállító kódok biztonságos helyen vannak-e?
44. **Biztonsági mentés:** automatikus-e, kiterjed-e a fájlokra, az adatbázisra és a táblázatokra, külön helyen tárolódik-e, és volt-e visszaállítási próba?
45. **Figyelés:** van-e uptime- és hibafigyelés (pl. értesítés, ha az oldal leáll vagy az űrlap hibát dob), és tanúsítvány-lejárati értesítés?
46. **Incidensterv röviden:** ha kiszivárog egy kulcs vagy feltörik az oldalt, mit kell cserélni, hol, milyen sorrendben, és kit kell értesíteni (GDPR szerint 72 órán belül a hatóságot, ha személyes adat érintett).

## A JELENTÉS FORMÁJA
Mentsd el a projekt gyökerébe `SECURITY-AUDIT.md` néven (gitignore-ba téve, ne kerüljön a repóba), és foglald össze itt is.

1. **Vezetői összefoglaló:** 5–8 mondat, a 3 legfontosabb teendővel.
2. **Felderítés:** a 0. lépés eredménye.
3. **Megállapítások táblázata:** azonosító | pont száma | súlyosság (Kritikus / Magas / Közepes / Alacsony / Info) | rövid leírás | bizonyíték | kihasználási forgatókönyv egy mondatban | javítás | ellenőrzés módja.
   - A súlyosságot a valós kihasználhatóság és a hatás alapján add meg, ne az alapján, hogy „hiányzik egy fejléc”. Egy statikus oldalon a hiányzó CSP alacsonyabb kockázat, mint egy kiszivárgott API-kulcs.
4. **Rendben lévő pontok:** röviden, hogy lássam, mit ellenőriztél.
5. **Kézi teendők:** amit kódból nem lehet megoldani (DNS, regisztrátor, tárhely-admin, fiókok), lépésenként.
6. **Javítási terv:** csomagokba szedve, súlyosság szerint. Csomagonként: mely fájlok változnak, mi törhet el, hogyan ellenőrizzük, hogyan lehet visszaállni.

## JAVÍTÁS (csak jóváhagyás után)
- Csomagonként haladj. Minden csomag után mutasd meg a diffet, futtasd a buildet és a teszteket (ha vannak), és ellenőrizd a fő funkciókat:
  - oldalbetöltés, navigáció, képek, betűtípusok;
  - űrlapküldés, analitika hozzájárulás után;
  - beágyazások.
- A CSP-t először Report-Only módban élesítsd, és csak akkor szigorítsd, ha nincs sértés.
- A végén futtasd újra az érintett ellenőrzéseket, és adj előtte–utána táblázatot.