Chrome biztonsági frissítés: 42 javítás egy hét alatt. Mit jelent a Chrome 153 és 154 a látogatóidnak?

A Google 2026. szeptember 15-én kiadott Chrome biztonsági frissítése a hivatalos Chrome Releases blog szerint egyetlen csomagban 42 sérülékenységet zárt be a 153-as verzióban, közülük hármat kritikus besorolással. Egy héttel korábban, szeptember 8-án a Chrome 153 első stabil kiadása 230 biztonsági javítást hozott, a Google pedig azt is megerősítette, hogy a V8 JavaScript-motor egyik hibáját már élesben kihasználják. Szeptember 16-án a Chrome 154 korai stabil kiadásként megjelent a Windows-felhasználók egy kis csoportjánál, másnap pedig újabb 16 javítás érkezett a 153-as ágra. A böngésző közben kéthetes kiadási ritmusra kapcsolt, amelyhez minden weboldalnak alkalmazkodnia kell.

Első ránézésre mindez a Google és a felhasználók ügye, hiszen a Chrome magától frissül. Weboldal-tulajdonosként mégis érdemes odafigyelned, mert a látogatóid egy része napokig vagy akár hetekig a régi, sérülékeny verzióval nyitja meg az oldaladat, a gyorsabb ritmus pedig azt is jelenti, hogy kéthetente változhat valami abban a szoftverben, amelyen a webshopod kosara, a foglalási űrlapod vagy az ügyfélportálod fut. A 2026. szeptember 22-i állapot szerint összeszedtük, mi történt pontosan, mennyiben érinti ez a látogatóid biztonságát, milyen beállításokkal (Content Security Policy, HTTPS, frissítési fegyelem) szűkítheted a kockázatot a saját oldaladon, végül azt is, hogyan figyelhetik automatikus Playwright-tesztek minden böngészőverzió után, hogy működik-e még minden.

Röviden

• A Google 2026. szeptember 15-én kiadott Chrome 153.0.8010.47/.48-as verziója a hivatalos Chrome Releases blog szerint 42 biztonsági javítást tartalmaz, köztük három kritikus hibát a WebGL grafikus felületben, az Internals nevű belső komponensben és a háttérszálakat kezelő Workersben.
• A szeptember 8-i Chrome 153.0.8010.36/.37 már 230 biztonsági javítást hozott, a Google pedig közölte, hogy a V8 JavaScript-motor CVE-2026-87491 azonosítójú hibájára létezik élesben használt támadókód, vagyis zero-day sérülékenységről volt szó.
• A javítás a látogató böngészőjében történik, de csak újraindítás után lép életbe, a Google pedig napok vagy hetek alatt, fokozatosan juttatja el mindenkihez, így egy ideig a látogatóid egy része biztosan sérülékeny verzióval böngészik.
• Weboldal-tulajdonosként a látogató böngészőjét nem tudod frissíteni, azt viszont igen, hogy az oldalad ne szolgáljon ki rosszindulatú kódot: ehhez szigorú Content Security Policy (CSP), kizárólag HTTPS-kapcsolat, naprakész CMS és minél kevesebb külső szkript kell.
• A Chrome a 153-as verziótól négy hét helyett kéthetente ad ki új főverziót, ezért a havi kézi ellenőrzésnél jobb biztosítás egy automatikus Playwright-tesztcsomag, amely a Chrome stabil és bétaverzióján is végigkattintja a kosarat, az űrlapokat és a foglalást.
• Saját becslésünk szerint egy KKV-weboldal biztonsági lépéstartása egyszeri 130 000 és 290 000 Ft közötti beállítás után havonta nagyjából 40 000 és 60 000 Ft közötti munkát igényel, ami egy webshopnál már egyetlen, napokig észrevétlen pénztárhibánál megtérülhet.

Mi történt a Chrome 153-ban? Három kritikus CVE a WebGL-ben és a Workersben

A Chrome 153-as verziója szeptember 8. és 17. között három biztonsági kiadást kapott az asztali stabil csatornán. A hivatalos Chrome Releases blog bejegyzései szerint a szeptember 8-i első kiadás 230, a szeptember 15-i 42, a szeptember 17-i pedig 16 biztonsági javítást tartalmazott, ami saját összesítésünk szerint tíz nap alatt 288 lezárt sérülékenységet jelent. Ez a szám elsőre ijesztő, valójában viszont annak a jele, hogy a Google, a külső kutatók és az automatikus hibakereső rendszerek folyamatosan dolgoznak a böngésző kódján, a talált hibák pedig gyorsan javításba kerülnek.

A címben szereplő 42 javítás tehát a szeptember 15-i kiadásra vonatkozik. Ebben a három kritikus hiba mellett 28 magas, 10 közepes és egy alacsony besorolású sérülékenység szerepel (saját számolásunk a kiadási jegyzet listája alapján). A három kritikus hiba a következő:

• CVE-2026-91726: határon túli olvasás (out of bounds read) a WebGL-ben, amelyet a Google saját csapata jelentett be szeptember 3-án.
• CVE-2026-91721: felszabadított memória újrahasználata (use after free) az Internals komponensben, egy xinyang nevű kutató bejelentése alapján, szeptember 4-i dátummal.
• CVE-2026-91749: szintén use after free típusú hiba, ezúttal a Workers komponensben, amelyet WinD39 (Huynh Dinh Vu) jelentett szeptember 8-án.

A dátumokból az is látszik, milyen gyors a javítási lánc: a Workers-hibát a bejelentés után hét nappal már javított verzió tartalmazta. A szeptember 17-i kiadás két újabb kritikus hibát zárt be, egy felszabadított memória újrahasználatát a Dawnban és egy puffertúlcsordulást (buffer overflow) a WebGL-ben, emellett hét magas, hat közepes és egy alacsony besorolású javítást hozott.

Mit jelent a CVE és a „kritikus” besorolás?

A CVE (Common Vulnerabilities and Exposures) a nyilvánosan ismert sérülékenységek nemzetközi nyilvántartása, a CVE-azonosító pedig olyan, mint egy ügyszám: a CVE-2026-91726 pontosan egy hibát jelöl, így bárki bárhol ugyanarról beszél, ha ezt a számot használja. A Chrome a hibákat négy fokozatba sorolja (Critical, High, Medium, Low, vagyis kritikus, magas, közepes és alacsony), a kritikus és a magas besorolás pedig azt jelzi, hogy a hiba kihasználása a legsúlyosabb következményekkel járhat.

A kiadási jegyzetekben két hibatípus neve tér vissza újra és újra. A use after free (felszabadítás utáni használat) azt jelenti, hogy a program olyan memóriaterülethez nyúl, amelyet korábban már felszabadított, holott ott addigra más adat is lehet. Az out of bounds read vagy write (határon túli olvasás vagy írás) pedig azt, hogy a program a számára kijelölt memóriaterületen kívülről olvas vagy oda ír. Mindkettő a C++ nyelven írt nagy szoftverek tipikus memóriabiztonsági hibája, a böngészőgyártók ezért is fektetnek sokat a homokozóba (sandbox), amely elzárja a weboldalak kódját az operációs rendszertől.

Mi az a WebGL, a Dawn és a Worker?

A WebGL az a böngészős programozási felület, amellyel a weboldalak a videokártya segítségével rajzolnak 2D és 3D grafikát. Ezt használják a forgatható 3D termékmegjelenítők, egyes interaktív térképek, a bútor- vagy konyhatervező konfigurátorok és sok látványos háttéranimáció. A Dawn a Chrome WebGPU-megvalósítása, vagyis az újabb generációs grafikus felület motorja, a Worker pedig olyan szkript, amely a weboldal mellett, egy háttérszálon fut. Ide tartoznak a Service Workerek is, amelyek az offline működést, a gyorsítótárazást és a push-értesítéseket intézik. Sok WordPress-bővítmény, például a push-értesítést vagy PWA-módot kínálók, szintén regisztrál ilyen Service Workert a látogató böngészőjében.

A lényeg weboldal-tulajdonosként: ezek a hibák a böngésző kódjában voltak, nem a te oldaladban, ezért a javításukhoz neked semmit nem kell átírnod. Ha viszont az oldalad WebGL-es 3D-nézegetőt, térképet vagy Service Workert használ, akkor pontosan ezek azok a részek, amelyeket egy nagyobb böngészőfrissítés után érdemes végigkattintani, hiszen egy javítás néha a működést is módosítja. Saját számolásunk szerint szeptember 8. és 17. között hat kritikus WebGL-hibát javítottak, ami jól mutatja, mennyire összetett terület a böngészők grafikus kódja.

Aktívan kihasznált zero-day a JavaScript-motorban: a CVE-2026-87491 röviden

A CVE-2026-87491 a Chrome V8 JavaScript-motorjának memóriahibája, pontosabban határon túli írás (out of bounds write), amelyre a Google szeptember 8-i közlése szerint már élesben használt támadókód létezik. A javítást a Chrome 153.0.8010.36-os és az annál újabb verziók tartalmazzák, a technikai részleteket a Google egyelőre nem hozza nyilvánosságra.

A zero-day (nulladik napi) sérülékenység olyan hiba, amelyet a támadók már azelőtt ismernek és kihasználnak, hogy a gyártó javítást adhatott volna ki rá, a védekezőknek tehát szó szerint nulla napjuk marad a felkészülésre. A V8 a Google nyílt forráskódú JavaScript- és WebAssembly-motorja, amely a Chrome-ban, a többi Chromium-alapú böngészőben (például a Microsoft Edge-ben) és a Node.js szerveroldali környezetben is futtatja a JavaScript-kódot. A modern weboldalak szinte minden interakciója rajta keresztül fut, ezért a V8 hibái különösen értékesek a támadók szemében.

A Chrome Releases blog szeptember 8-i bejegyzése egyetlen rövid mondatban közölte a lényeget, amely saját fordításunkban így szól: „A Google tud róla, hogy a CVE-2026-87491-re létezik kihasználó kód a gyakorlatban.” A hibát a kiadási jegyzet szerint Jihyeon Jeong, a Szöuli Nemzeti Egyetem Compsec Laborjához köthető kutató jelentette be augusztus 6-án, amiért 2 500 dolláros jutalmat kapott a Google hibavadász-programjából. A SecurityWeek összesítése szerint ez volt 2026 hetedik aktívan kihasznált Chrome zero-day hibája, vagyis a jelenség egyáltalán nem ritka.

Miért csak „közepes” a besorolása, ha már támadják?

Érdekes részlet, hogy a Google a CVE-2026-87491-et közepes (Medium) súlyosságúnak sorolta be, miközben a szeptember 8-i kiadás öt kritikus hibájáról nem jelezte, hogy bármelyiket kihasználnák. A besorolás azt méri, mekkora kárt okozhat egy hiba elméletben, a „kihasználják élesben” jelzés viszont azt, hogy valaki már a gyakorlatban is él vele. A sürgősség szempontjából az utóbbi a döntő, hiszen egy aktívan kihasznált közepes hiba ma veszélyesebb lehet, mint egy kritikus, amelyről egyelőre csak a fejlesztők tudnak. Ugyanez a logika érvényes egy WordPress-bővítmény vagy egy webshopmotor biztonsági közleményére is.

Miért nem árul el többet a Google?

A Chrome kiadási jegyzeteiben minden alkalommal szerepel egy mondat, amely szerint a hibák részletei és a kapcsolódó linkek korlátozottak maradhatnak, amíg a felhasználók többsége meg nem kapja a javítást. Ennek egyszerű oka van: minél több technikai részlet nyilvános, annál könnyebb a még nem frissített gépek ellen fordítani a tudást. Emiatt olvasol a hírekben mindig csak annyit, hogy „V8”, „WebGL” vagy „use after free”. A te szempontodból egyetlen adat számít igazán: az a verziószám, amely már tartalmazza a javítást.

A mesterséges intelligencia ráadásul tovább gyorsítja a hibák felfedezését: az OpenAI szeptember 3-án bemutatott GPT-6 Astra modellje a tesztelése során két korábban ismeretlen zero-day hibát talált. Erről az AI és a kiberbiztonság kapcsolatáról szóló cikkünkben írtunk részletesen, itt elég annyi, hogy a javítások üteme várhatóan inkább gyorsulni fog, mint lassulni.

Mi az a Chrome biztonsági frissítés és hogyan jut el a látogatóidhoz?

A Chrome biztonsági frissítése a böngésző olyan új verziója, amely ismert sérülékenységeket javít. A Chrome a háttérben magától letölti, de csak a böngésző újraindítása után lép életbe, a Google pedig a kiadási jegyzetek szerint a következő napokban és hetekben, fokozatosan juttatja el a felhasználókhoz.

A fokozatos bevezetés (rollout) jó okkal működik így: ha egy frissítés váratlan hibát okoz, azt még azelőtt észre lehet venni, hogy mindenkit elérne. A mellékhatása viszont az, hogy a kiadás napján a látogatóidnak csak egy része kapja meg a javítást, a többiek pedig napokig a korábbi verziót futtatják. Ehhez jön még az újraindítás kérdése, ami a gyakorlatban a leggyengébb láncszem. A Chrome jobb felső sarkában megjelenő frissítésjelzés mutatja, hogy a javítás letöltődött és újraindításra vár, sokan azonban hetekig nem zárják be a böngészőt, a laptopot pedig csak lecsukják.

A csatornák közötti különbség is számít, ha a látogatóid között sok a céges felhasználó:

• A stabil csatorna az, amelyet a legtöbben használnak; szeptember 15-én ide érkezett a 153.0.8010.47/.48 a 42 javítással.
• Az Extended Stable a vállalatoknak szóló, lassabban változó csatorna, amely a szeptember 15-i és 17-i kiadások szerint még a 152-es főverzión maradt (152.0.7977.130, majd .134), a biztonsági javításokat viszont hetente megkapja.
• A korai stabil (Early Stable) kiadás a következő főverziót egy kis felhasználói körnek adja ki elsőként, a Chrome 154.0.8037.44/.45 szeptember 16-án így jutott el a Windows-felhasználók egy kis részéhez.
• Az androidos Chrome külön frissül a Google Playen keresztül, a Chrome Releases blog szeptember 15-én, 16-án és 17-én is jelentett androidos kiadást.

Mit jelent a Chrome 153 és 154 a látogatóidnak?

A látogatóidnak a frissítés elsősorban védelmet jelent, mert a javított böngészőben a mostani hibák már nem használhatók ki. A kockázat abban az időablakban van, amíg valaki még régi verziót futtat: ilyenkor bármely meglátogatott oldal, egy feltört céges weboldal vagy egy rosszindulatú hirdetés lehet a támadás kiindulópontja.

A böngészőmotor hibáit jellemzően rosszindulatú webes tartalom indítja el, vagyis a támadónak el kell érnie, hogy az áldozat böngészője megnyissa a csapdát. Ez lehet egy kifejezetten erre készült oldal, de lehet egy teljesen ártatlan cég weboldala is, ha valaki előtte rosszindulatú kódot csempészett bele. Weboldal-tulajdonosként tehát nem az a kérdés, hogy a látogatóid böngészője sérülékeny-e (egy részüké biztosan az), hanem az, hogy a te oldalad lehet-e az a hely, ahol a sérülékeny böngésző találkozik a rosszindulatú kóddal.

Egy átlagos KKV-weboldal négy úton válhat ilyen kiindulóponttá:

• Elavult CMS vagy bővítmény, amelyen keresztül valaki idegen szkriptet illeszt az oldalba (ezért sürgős például a WordPress 7.1.1 telepítése, amelyről külön cikkben írtunk).
• Feltört külső szolgáltató, akinek a kódja az oldaladon fut: chatablak, értékelésmodul, A/B tesztelő, hőtérkép vagy bármilyen „csak egy sor kód” típusú beépülő.
• Hirdetési hálózat, amely rosszindulatú hirdetést (malvertising) jelenít meg a hirdetési felületeiden.
• Szűretlen felhasználói tartalom, például hozzászólás, értékelés vagy fórumbejegyzés, amelyben kód is átcsúszhat.

Egyik esetben sem a Chrome hibás, a következmény viszont a te neved alatt jelenik meg. Ha a Google Safe Browsing rendszere rosszindulatú tartalmat talál az oldaladon, a látogatók piros figyelmeztető képernyőt láthatnak a Chrome-ban, a Google Search Console Biztonsági problémák jelentésében pedig megjelenik a riasztás. Ha személyes adat is érintett, a GDPR szerint az adatvédelmi incidenst általában 72 órán belül be kell jelenteni a Nemzeti Adatvédelmi és Információszabadság Hatóságnak (NAIH), ami egy kis cégnél napokra leköti a vezetés figyelmét.

Három képzeletbeli látogatói kör, háromféle kockázat

Tegyük fel, hogy egy győri gépalkatrész-forgalmazó B2B webshopot üzemeltet. A vásárlói többnyire irodai gépekről rendelnek, ahol a böngészőt a céges informatika felügyeli: egy részük az Extended Stable csatornán van, másoknál a Chrome hetekig nyitva marad harminc füllel. Ennél a cégnél a látogatók jelentős része a frissítés után is napokig régi verziót futtat, a kosár és az ajánlatkérő űrlap pedig üzletileg a legfontosabb felület, ezért itt a külső szkriptek számának visszavágása és a szigorú CSP hozza a legtöbbet.

Vegyünk egy képzeletbeli balatoni panziót is, amelynek a vendégei nagyrészt mobilról foglalnak. Az androidos Chrome a Google Playen keresztül frissül, ami a legtöbb telefonon gyorsan megtörténik, a régebbi, már nem támogatott Android-verziókon viszont egy idő után a Chrome sem kap új verziót. Itt a HTTPS és a beágyazott foglalási motor rendbetétele a fontosabb, mert a vendégek gyakran nyilvános wifin böngésznek, ahol egy titkosítatlan oldal tartalmát útközben is meg lehet változtatni.

Harmadik példának vegyünk egy szegedi fogorvosi rendelőt, amelynek online időpontfoglalója egészségügyi adatokat is kezel. Itt a látogatók böngészőjének állapota mellett az számít a legjobban, hogy a foglalási és adatlapokon semmilyen felesleges külső kód ne fusson, mert egy ott megjelenő idegen szkript elvben mindent láthat, amit a páciens begépel. Az egészségügyi adat a GDPR szerint különleges kategóriájú személyes adat, így egy incidens itt jóval súlyosabb következményekkel jár, mint egy hírlevél-feliratkozásnál.

Mit tehetsz közvetlenül a látogatókért?

A látogató böngészőjét nem tudod helyette frissíteni, erőltetni pedig nem is érdemes. A régi böngészőket kitiltó oldalak rendszerint több kárt okoznak, mint hasznot, hiszen a böngészőazonosító (user agent) alapján történő felismerés pontatlan, a kitiltott látogató pedig egyszerűen átmegy a konkurenciához. Egy diszkrét, csak nagyon régi verzióknál megjelenő sáv, amely a frissítésre emlékeztet, elfogadható kompromisszum lehet, a valódi védelmet viszont az adja, amit a saját oldaladon rendbe teszel. Erről szól a következő szakasz.

Miért fontos a CSP, a HTTPS és a frissítési fegyelem a te oldaladon?

Mert a Chrome biztonsági frissítése a látogató gépét védi, a Content Security Policy, a HTTPS és a rendszeres frissítés viszont azt biztosítja, hogy a te oldalad ne szolgáljon ki rosszindulatú kódot. A három együtt úgy szűkíti a támadási felületet, hogy egy még nem frissített böngészőt se a te weboldaladon keresztül érjen baj.

Content Security Policy: vendéglista a szkripteknek

A Content Security Policy (CSP) egy HTTP-válaszfejléc, amellyel a weboldal megmondja a böngészőnek, hogy milyen forrásokból tölthet be szkriptet, stílust, képet, betűtípust vagy beágyazott keretet, minden mást pedig letilt. Olyan ez, mint egy rendezvény vendéglistája a bejáratnál: aki nincs rajta, nem jut be, akármilyen meggyőzően érvel is. Ha valaki egy elavult bővítményen keresztül egy idegen domainről betöltődő szkriptet csempész az oldaladba, a CSP-vel védett oldalon a böngésző egyszerűen megtagadja a betöltését, a fejlesztői konzolba pedig hibaüzenetet ír.

Egy kiinduló, még csak figyelő (Report-Only) módban futó szabály egy Google Tag Managert használó oldalon nagyjából így nézhet ki (az olvashatóság kedvéért tördelve, a valóságban egyetlen fejlécsor):

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  img-src 'self' data: https:;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'self'

A valóságban a Tag Manager beillesztő kódja miatt nonce is kell, minden további címke (Meta Pixel, chat, fizetés) pedig újabb bejegyzést igényel. A jelentések fogadásához egy report-to vagy report-uri direktívával megadott gyűjtőcím is szükséges, erre küldik el a böngészők a szabálysértéseket.

A CSP-nek két korlátját érdemes tisztán látni. Egyrészt nem javítja a böngésző hibáit, csak azt akadályozza meg, hogy a te oldaladon keresztül idegen kód jusson a látogatóhoz. Másrészt nem véd, ha egy engedélyezett külső szolgáltatót törnek fel, hiszen az ő domainje rajta van a vendéglistán. Ez ellen a nem változó, verziózott fájloknál a Subresource Integrity (SRI) segít, amely a betöltött fájl ujjlenyomatát ellenőrzi. A legjobb védekezés viszont továbbra is az, ha kevesebb külső szkriptet használsz.

A Google fejlesztői dokumentációja az úgynevezett szigorú, nonce-alapú CSP-t ajánlja, amelyben minden engedélyezett szkript egy oldalbetöltésenként változó, véletlenszerű azonosítót kap. Ez erősebb a domainlistánál, egy WordPress-oldalon viszont a bővítmények sok beágyazott (inline) szkriptje miatt több munkával jár, ezért a legtöbb KKV-nak a fokozatos út a reális.

HTTPS és HSTS: miért lesz gyanús a titkosítatlan oldal?

A HTTPS titkosítja a látogató és a szerver közötti forgalmat, ráadásul garantálja, hogy útközben senki ne módosíthassa az oldal tartalmát. Ez a böngészőhibák szempontjából is lényeges, mert egy titkosítatlan HTTP-oldalba egy nyilvános wifi vagy egy feltört router rosszindulatú kódot fűzhet, HTTPS mellett viszont erre nincs mód. A HSTS (HTTP Strict Transport Security) fejléc ezt megerősíti, mert utasítja a böngészőt, hogy a domainedet a jövőben kizárólag HTTPS-en nyissa meg.

A téma a Chrome 154 miatt különösen aktuális. Több szakmai lap, köztük az Infosecurity Magazine és a Semonto beszámolója szerint a Google terve az, hogy a Chrome 154-es verziójától alapértelmezetten bekapcsol az „Always Use Secure Connections” (mindig biztonságos kapcsolat használata) beállítás, vagyis a böngésző megkérdezi a látogatót, mielőtt egy nyilvános oldalt titkosítatlan HTTP-kapcsolaton nyitna meg. Ha az oldal elérhető HTTPS-en, a Chrome egyszerűen átvált rá, figyelmeztetést csak az lát, aki olyan címre téved, amely kizárólag titkosítatlanul működik. A kéthetes kiadási ritmus miatt a 154-es verzió a korábban vártnál hamarabb, már szeptember végén érkezik, ezért a pontos bekapcsolási időpontot a Google hivatalos közleményeiből követheted nyomon.

A gyakorlatban a veszélyt az elfelejtett címek jelentik: egy régi hírlevélben szereplő http:// link, egy nyomtatott szórólapon lévő QR-kód, egy régi aldomain (például egy valamikori kampányoldal) vagy egy külső rendszer, amely még mindig titkosítatlanul hivatkozik rád. Ezeket célszerű most felkutatni és 301-es átirányítással a HTTPS-es címre terelni, a HSTS-t pedig csak azután bekapcsolni, hogy minden aldomain biztosan működik HTTPS-en.

Frissítési fegyelem: a böngésző kéthetente frissül, a te oldalad?

A harmadik elem a legkevésbé látványos, mégis a legtöbbet érő. A böngészőgyártó a saját kódját gyorsan javítja, a te oldaladon futó CMS, bővítmények, sablonok és keretrendszerek frissítése viszont rajtad vagy az üzemeltetődön múlik. A szeptemberi hetek jól mutatják a tempót: a WordPress 7.1.1 szeptember 17-én 11 biztonsági javítással jelent meg, a Next.js csapata pedig szeptember 22-én soron kívüli kritikus biztonsági frissítést adott ki a 16.3.6-os és a 15.5.26-os verzióban egy külső függőség hibája miatt. Aki ezekre hetekig nem reagál, annak az oldala pont olyan kiindulóponttá válhat, amelyről fentebb írtunk.

Egy működő frissítési rend nem bonyolult. Kritikus, különösen aktívan kihasznált hibánál 24 és 48 órán belül kerüljön fel a javítás, a többi frissítés heti vagy kétheti ciklusban, mindig friss biztonsági mentéssel és egy gyors ellenőrzéssel a legfontosabb oldalakon. A bővítményeknél a legjobb frissítés gyakran a törlés: ami egy éve nem kapott frissítést és nem is használjátok, az csak támadási felület.

A legfontosabb biztonsági fejlécek egy táblázatban

A CSP és a HSTS mellett néhány további HTTP-fejléc is sokat javít a helyzeten, a beállításuk pedig általában csak percek kérdése a szerveren vagy a CDN-ben:

Hogyan vezesd be a CSP-t lépésről lépésre?

A CSP-t úgy érdemes bevezetni, hogy először csak figyelő (Report-Only) módban fut és egy-két hétig gyűjti a jelentéseket, élesre pedig csak a lista letisztázása után kapcsolod. Így a látogatók semmit nem vesznek észre a bevezetésből, te viszont pontos képet kapsz arról, milyen kód fut valójában az oldaladon.

• Leltár. Nyisd meg az oldal legfontosabb aloldalait (főoldal, termékoldal, kosár, pénztár, kapcsolat) a böngésző fejlesztői eszközeiben, majd a Hálózat (Network) fülön írd össze, milyen külső domainről töltődik be szkript, stílus, betűtípus és keret.
• Selejtezés. Húzd ki a listáról mindazt, amit senki nem használ: a régi A/B tesztelőt, a két éve kikapcsolt hőtérképet, a már nem futó kampány pixelét. Minden törölt szkript eggyel kevesebb kockázat, ráadásul általában gyorsabb oldal is.
• Figyelő mód. Állítsd be a Content-Security-Policy-Report-Only fejlécet a leltár alapján, egy jelentésgyűjtő címmel (report-to vagy report-uri), amelyre a böngészők elküldik a szabálysértéseket.
• Gyűjtés. Hagyd futni legalább egy-két hétig, hogy a ritkán használt funkciók (fizetés, kuponbeváltás, hírlevél-feliratkozás, térkép) is sorra kerüljenek.
• Tisztázás. Nézd át a jelentéseket: a jogos forrásokat vedd fel a szabályba, a beágyazott (inline) szkripteket lásd el nonce-szal vagy hash-sel, az ismeretlen forrásoknál pedig derítsd ki, honnan kerültek oda.
• Próba. Élesítsd a szabályt egy tesztkörnyezetben, majd futtasd le rajta a teljes vásárlási, foglalási és űrlapkitöltési folyamatot, lehetőleg automatikus tesztekkel.
• Élesítés. Kapcsold át a fejlécet Content-Security-Policy-ra az éles oldalon, de a jelentéseket továbbra is gyűjtsd.
• Karbantartás. Minden új marketingeszköz bekötésekor és negyedévente legalább egyszer nézd át a szabályt, mert a CSP csak addig véd, amíg naprakész.

A leggyakoribb buktatók tapasztalatunk szerint a Google Tag Managerben felvett egyedi HTML-címkék, amelyek beágyazott szkriptet szúrnak az oldalba, ezért nonce nélkül a CSP letiltja őket. Gyakori gond a bankkártyás fizetés háromlépcsős hitelesítése (3-D Secure) is, amelynek ablaka a kártyakibocsátó bank domainjéről töltődhet be, valamint a sütihozzájárulást kezelő sávok, amelyek maguk is több külső szkriptet húznak be. Ezeket mindig a teljes folyamaton, valódi tesztvásárlással ellenőrizd, ne csak a főoldalon.

Automatikus tesztelés Playwrighttal minden böngészőverzió után

A Playwright a Microsoft nyílt forráskódú böngészőautomatizáló és tesztelő eszköze, amely ugyanazokat a felhasználói utakat a Chromium, a Firefox és a WebKit motorján, valamint a márkázott Chrome stabil és béta csatornáján is le tudja futtatni. Ha naponta és minden Chrome-kiadás után futtatod, a hibát te veszed észre elsőként, nem a vásárlód.

Az automatikus tesztelés lényege egyszerű: amit egy gondos kolléga minden frissítés után kézzel végigkattintana, azt egy program kattintja végig percek alatt, minden alkalommal ugyanúgy. A Playwright megnyitja az oldalt egy valódi böngészőben, termékeket tesz a kosárba, kitölti az űrlapot és ellenőrzi, hogy megjelent-e a visszaigazolás. Ha valami eltér, képernyőképpel és részletes nyomkövetéssel (trace) jelzi, hol akadt el a folyamat.

Erre azért van szükség, mert kéthetente a böngésző is változik, közben pedig a te oldalad is (frissül a CMS, új bővítmény vagy marketingkód kerül fel), a kettő együttes hatását pedig csak rendszeres teszteléssel lehet követni.

Mit tesztelj először?

Nem kell mindent tesztelni. Egy KKV-weboldalnál öt-tíz jól megválasztott felhasználói út lefedi a bevétel és a kapcsolatfelvétel szinte teljes egészét:

• a kosár és a pénztár a fizetési szolgáltató tesztüzemmódjában (a Barion, a SimplePay és a Stripe is kínál ilyen tesztkörnyezetet)
• az ajánlatkérő és a kapcsolatfelvételi űrlap egy tesztpostafiókkal, a visszaigazoló e-maillel együtt
• az online foglalás vagy időpontfoglalás egy tesztnaptárral
• a bejelentkezés és a jelszó-visszaállítás az ügyfélportálon
• a sütihozzájárulási sáv, mert ha ez elromlik, a mérés és a remarketing is leáll
• a mobilmenü és a keresés telefonméretű nézetben
• a WebGL-es 3D-nézegető, a térkép vagy a Service Workert használó funkciók, ha vannak ilyenek

Hogyan állítsd be lépésről lépésre?

• Válaszd ki a felhasználói utakat. Az előző lista alapján rögzítsd, melyik öt-tíz folyamat nem romolhat el soha, illetve mi számít sikernek (például megjelenik a „Köszönjük a rendelését” oldal).
• Rögzítsd a lépéseket. A Playwright beépített rögzítője (npx playwright codegen, utána az oldal címe) kattintásról kattintásra felveszi, amit csinálsz, a fejlesztő pedig ebből készít tiszta, karbantartható tesztet.
• Add meg a böngészőket. A Playwright alapból a saját, verziójához igazított Chromium-, Firefox- és WebKit-buildjeivel dolgozik, a márkázott Chrome stabil és béta csatornáját külön kell telepíteni (npx playwright install chrome-beta), majd projektként felvenni a konfigurációba.
• Figyeld a konzolt is. Állítsd be, hogy a teszt akkor is hibát jelezzen, ha a böngésző konzoljában JavaScript-hiba vagy CSP-szabálysértés jelenik meg, mert ezek gyakran előbb szólnak, mint ahogy egy gomb láthatóan elromlik.
• Kérj vizuális összehasonlítást. A toHaveScreenshot() ellenőrzés képpontonként összeveti az oldalt egy korábban elfogadott mintaképpel, így az elcsúszott gombokat és a szétesett elrendezést is elkapja.
• Ütemezd a futtatást. Egy CI-rendszerben (például GitHub Actions vagy GitLab CI) állítsd be, hogy a tesztek minden éjjel, minden éles telepítés után és minden új Chrome-kiadás napján lefussanak.
• Jelöld ki a felelőst. A hibajelzés e-mailben vagy Teams-, illetve Slack-üzenetben menjen egy konkrét emberhez, aki 24 órán belül ránéz.
• Tartsd karban. Havonta egy-két órában nézd át a teszteket, mert minden oldalváltozás (új menüpont, átnevezett gomb) igazítást igényelhet.

Egy ilyen beállítás konfigurációja meglepően rövid, a lényeg néhány sor, amely négy böngészőt vesz fel projektként:

// playwright.config.ts (részlet)
projects: [
  { name: 'chrome-stabil', use: { channel: 'chrome' } },
  { name: 'chrome-beta', use: { channel: 'chrome-beta' } },
  { name: 'firefox', use: { browserName: 'firefox' } },
  { name: 'webkit', use: { browserName: 'webkit' } },
],

Ha a béta projekt elbukik, a stabil pedig nem, jó eséllyel még azelőtt van időd javítani, hogy a változás a látogatóidhoz érne. A WebKit-motoros futtatás a Safarihoz áll közel, de nem azonos vele, ezért egy iPhone-os kézi ellenőrzést negyedévente így is érdemes beiktatni.

Mennyibe kerül és kinek éri meg?

Maga a Playwright ingyenes, nyílt forráskódú eszköz, a futtatáshoz szükséges CI-kapacitás pedig egy kisebb tesztcsomagnál sok esetben belefér a szolgáltatók ingyenes keretébe. A költséget a munka adja: saját becslésünk szerint, 10 000 Ft-os fejlesztői óradíjjal számolva, öt-tíz felhasználói út lefedése 80 000 és 160 000 Ft közötti egyszeri költség, a karbantartás pedig havonta 10 000 és 20 000 Ft.

Hogy ez sok vagy kevés, azt egy egyszerű számítás mutatja meg. Vegyük a képzeletbeli győri B2B webshopot napi 600 000 Ft forgalommal, feltételezve, hogy a rendelések fele Chrome-ból érkezik. Ha egy böngészőváltozás miatt a pénztár gombja két napig észrevétlenül nem működik Chrome-ban, az 600 000 × 0,5 × 2, vagyis 600 000 Ft elmaradt forgalom, nem számolva a bosszús ügyfeleket, akik legközelebb máshol rendelnek. Egyetlen ilyen eset tehát nagyjából annyiba kerül, mint a teljes tesztcsomag kiépítése.

Egy egyoldalas bemutatkozó oldalnak űrlap és bolt nélkül viszont a teljes tesztcsomag túlzás, ott elég egy havi kézi ellenőrzés és a biztonsági fejlécek rendbetétele. Minden olyan oldalnak, amelyen pénz, foglalás vagy ügyféladat mozog, a Playwright-tesztcsomag az egyik legjobb ár-érték arányú befektetés a weboldal üzemeltetésében.

Mit jelent a kéthetes kiadási ciklus a weboldal-üzemeltetésnek?

A DropTimes szaklap szeptember 14-i összefoglalója szerint a Chrome 153 az első stabil főverzió, amely már a négyhetes helyett kéthetes ütemben érkezett. Weboldal-üzemeltetési szempontból ez több, de kisebb változást jelent: gyorsabban jönnek a javítások és az új funkciók, viszont rövidebb idő marad a bétaverzión tesztelni.

Ugyanez az összefoglaló arról is beszámolt, hogy a Chrome 154 stabil kiadását szeptember 22-re ütemezték, az Extended Stable csatorna pedig továbbra is nyolchetes főverzió-ciklusban halad, heti rendszerességű biztonsági javításokkal. A hivatalos Chrome Releases blogon a 154-es verzió szeptember 16-án korai stabil kiadásként jelent meg a Windows-felhasználók egy kis részénél, ami egybevág ezzel az ütemtervvel. Az új ritmus a gyakorlatban négy dolgot változtat meg:

• A havi ellenőrzés már kevés. Ha csak havonta egyszer nézed meg az oldalt, két Chrome-főverzió is lecserélődhet közben, utólag pedig nehéz kideríteni, melyik okozta a hibát.
• A bétaverzió a korai figyelmeztetés. A Chrome béta csatornája jellemzően egy főverzióval jár a stabil előtt, így ha az automatikus tesztek ott is futnak, egy várható problémáról nagyjából két héttel korábban értesülsz, mint a látogatóid.
• Az új CSS- és HTML-funkciók gyorsabban érkeznek. Ez jó hír a fejlesztőknek, de progresszív módon érdemes építeni rájuk (a @supports szabállyal ellenőrizve), mert a Safari és a Firefox a saját tempójában követi őket. Az újdonságokról az új CSS-funkciókról szóló cikkünkben írtunk bővebben.
• A kivezetések is kisebb lépésekben jönnek. A régi, elavult böngészőfunkciók eltávolítása várhatóan szintén sűrűbb ütemben történik, ezért egy régóta nem frissített oldalon nagyobb az esélye egy váratlan hibának.

Céges gépeken az Extended Stable csatorna ad némi fékezési lehetőséget, egy nyilvános weboldal üzemeltetője viszont ezt nem választhatja a látogatóinak, neki ezért a gyakori, automatikus ellenőrzés marad.

A saját csapatod böngészői: újraindítás, házirend és kevesebb bővítmény

A csapat böngészői azért számítanak, mert ezekről nyitjátok meg a weboldal adminfelületét, a webshop hátterét, a netbankot és a hirdetési fiókokat. A legfontosabb szabály a heti újraindítás és a verzió ellenőrzése, céges környezetben pedig érdemes központi házirenddel kikényszeríteni az újraindítást.

Egy frissítés csak akkor véd, ha a böngésző újraindult. Ezt a legegyszerűbben a Chrome beállításai között található névjegyoldalon (chrome://settings/help) ellenőrizheted: itt látszik az aktuális verziószám, a Chrome itt keres frissítést is, találat esetén pedig újraindítást kér. A 2026. szeptember 22-i állapot szerint az asztali stabil csatornán legalább a 153.0.8010.52-es verziót kell látnod (Windowson és Macen .53 is lehet), a 154-es főverzió pedig fokozatosan érkezik.

• Heti újraindítás. Legyen szokás, hogy pénteken mindenki bezárja és újranyitja a böngészőt, a megnyitott fülek a helyreállítás után úgyis visszajönnek.
• Központi házirend. A Chrome vállalati házirendjeivel (például a RelaunchNotification és a RelaunchNotificationPeriod beállítással) az informatikus előírhatja, hogy a böngésző a frissítés után adott időn belül újrainduljon.
• Kevesebb bővítmény. A szeptember 15-i és 17-i kiadásban is több javítás érintette a bővítmények (Extensions) kezelését, ezért az adminmunkára használt böngészőprofilban csak a feltétlenül szükséges bővítmények maradjanak.
• Külön profil az adminnak. A weboldal, a webshop és a hirdetési fiókok kezelésére jobb egy külön Chrome-profilt használni, amelyben nincs felesleges bővítmény és amelyből a munkatárs nem böngészik szabadidőben.
• Kétfaktoros belépés. Ha egy böngésző mégis kompromittálódik, a második hitelesítési lépés megnehezíti a fiókok átvételét; erről az AI és a kiberbiztonság kapcsolatáról szóló cikkünkben részletesebben írtunk.

Egy képzeletbeli 12 fős irodában mindez fejenként havonta néhány percet vesz igénybe, egy kompromittált adminfiók helyreállítása viszont napokat vihet el, így a heti újraindítás a legolcsóbb biztonsági intézkedés, amelyet egy cégvezető holnaptól bevezethet.

Mennyibe kerül a lépéstartás és mit ellenőrizz havonta?

Saját becslésünk szerint egy KKV-weboldal biztonsági lépéstartása egyszeri 130 000 és 290 000 Ft közötti beállítással indul, utána havonta nagyjából 40 000 és 60 000 Ft közötti munkát igényel, 10 000 Ft-os óradíjjal számolva. A pontos összeg az oldal méretétől, a külső szkriptek számától és a meglévő tesztektől függ.

Az egyszeri tételek összesen 13 és 29 óra közötti munkát jelentenek (130 000 és 290 000 Ft között), a rendszeres tételek pedig havi 4 és 6 óra közöttit (40 000 és 60 000 Ft között). A táblázat egy átlagos, 20 és 50 aloldal közötti céges oldallal vagy egy kisebb webshoppal számol. Egy sok bővítményes WooCommerce-áruháznál a frissítés több időt visz el, egy egyszerű bemutatkozó oldalnál kevesebbet. Ha spórolni kell, a frissítésen ne spórolj: CSP és automatikus tesztek nélkül is lehet elfogadhatóan biztonságos egy jól karbantartott oldal, frissítések nélkül viszont a legjobb fejlécek sem mentik meg.

A havi rutin öt kérdésre szűkíthető, amelyeket egy nem fejlesztő cégvezető is feltehet az üzemeltetőjének:

• Milyen verzión fut a CMS és a bővítmények, volt-e olyan kritikus javítás, amely még nincs fent?
• Lefutottak-e hiba nélkül az automatikus tesztek az utolsó két Chrome-kiadás után?
• Jelzett-e a CSP ismeretlen forrást az elmúlt hónapban?
• Került-e új külső szkript az oldalra, ha igen, ki kérte és miért?
• Mutat-e bármit a Google Search Console Biztonsági problémák jelentése?

Miben segít a Convergo?

Ha nem szeretnél kéthetente Chrome-kiadási jegyzeteket olvasni, a Convergo support és üzemeltetési csomagja (30 000 Ft/hó, három fejlesztői órával) fedezi a CMS és a bővítmények mentéssel végzett frissítését, a biztonsági fejlécek karbantartását és a hibajelzések átnézését. A Content Security Policy bevezetését és a Playwright-alapú automatikus tesztcsomag felépítését programozás és egyedi fejlesztés keretében, 10 000 Ft-os óradíjjal vállaljuk. Ha először azt szeretnéd látni, hol áll most az oldalad, az IT audit és digitális tanácsadás szolgáltatásunk ezt feltérképezi. Az első lépés egy ingyenes egyeztetés, amelyen átnézzük az oldalad fejléceit, frissítési állapotát és külső szkriptjeit.