Webalkalmazások megerősítése: Mélyreható betekintés a JavaScript Content Security Policy (CSP) világába

Napjaink összekapcsolt digitális világában a webalkalmazások biztonsága elsődleges fontosságú. A rosszindulatú szereplők folyamatosan keresik a kihasználható sebezhetőségeket, és egy sikeres támadás adatvédelmi incidensekhez, pénzügyi veszteségekhez és súlyos hírnévkárosodáshoz vezethet. Az olyan gyakori webes fenyegetésekkel szembeni leghatékonyabb védekezési módok egyike, mint a Cross-Site Scripting (XSS) és az adatinjekció, a robusztus biztonsági fejlécek implementálása. Ezek közül a Content Security Policy (CSP) emelkedik ki, mint egy különösen hatékony eszköz, főként a JavaScript végrehajtás kezelésekor.

Ez az átfogó útmutató végigvezeti Önt a JavaScript Content Security Policy implementálásának és kezelésének bonyodalmain, gyakorlatias betekintést és példákat nyújtva egy globális közönség számára. Legyen Ön tapasztalt fejlesztő, vagy csak most kezdi útját a webbiztonság területén, a CSP megértése kulcsfontosságú lépés a rugalmasabb webalkalmazások építése felé.

Mi az a Content Security Policy (CSP)?

A Content Security Policy (CSP) egy további biztonsági réteg, amely segít felismerni és enyhíteni bizonyos típusú támadásokat, beleértve a Cross-Site Scripting (XSS) és az adatinjekciós támadásokat. Ez egy HTTP válaszfejléc, amely megmondja a böngészőnek, hogy mely dinamikus erőforrások (szkriptek, stíluslapok, képek stb.) betöltése engedélyezett az adott oldalon. Az engedélyezett források fehérlistájának megadásával a CSP jelentősen csökkenti a webalkalmazás támadási felületét.

Gondoljon a CSP-re úgy, mint egy szigorú kapuőrre a weboldalán. Ahelyett, hogy passzívan engedélyezné bármely szkript futtatását, Ön explicit módon meghatározza, honnan származhatnak a szkriptek. Ha egy szkript egy jogosulatlan forrásból próbál betöltődni, a böngésző blokkolni fogja, megakadályozva a potenciális rosszindulatú végrehajtást.

Miért kulcsfontosságú a CSP a JavaScript biztonsága szempontjából?

A JavaScript, amely az interaktív és dinamikus webes élmények gerincét képezi, egyben a támadók elsődleges célpontja is. A rosszindulatú JavaScript a következőkre képes:

• Érzékeny felhasználói adatok (pl. sütik, munkamenet tokenek, személyes adatok) ellopása.
• Felhasználók átirányítása adathalász oldalakra.
• Műveletek végrehajtása a felhasználó nevében, annak beleegyezése nélkül.
• Nem kívánt tartalom vagy hirdetések beillesztése.
• Felhasználók böngészőinek „cryptojackingje” kriptovaluta bányászatra.

Különösen az XSS támadások gyakran építenek rosszindulatú JavaScript kód weboldalakba történő beillesztésére. A CSP közvetlenül harcol ez ellen azáltal, hogy szabályozza, honnan futtatható a JavaScript. Alapértelmezés szerint a böngészők engedélyezik az inline szkripteket és a dinamikusan kiértékelt JavaScriptet (mint például az `eval()`). Ezek gyakori vektorok az XSS számára. A CSP lehetővé teszi ezen veszélyes funkciók letiltását és szigorúbb ellenőrzések bevezetését.

Hogyan működik a CSP: A Content-Security-Policy fejléc

A CSP implementálása a Content-Security-Policy HTTP fejléc webszerverről a böngésző felé történő küldésével valósul meg. Ez a fejléc egy sor direktívát tartalmaz, amelyek meghatározzák a biztonsági irányelvet. Minden direktíva egy adott típusú erőforrás betöltését vagy végrehajtását szabályozza.

Itt egy CSP fejléc alapvető szerkezete:

            Content-Security-Policy: directive1 value1 value2; directive2 value3; ...
            

              
                Copy
              
            
          

Bontsuk le a JavaScript biztonsága szempontjából releváns kulcsfontosságú direktívákat:

Kulcsfontosságú direktívák a JavaScript biztonságához

script-src

Ez vitathatatlanul a legkritikusabb direktíva a JavaScript biztonsága szempontjából. Meghatározza a JavaScript számára engedélyezett forrásokat. Alapértelmezés szerint, ha a script-src nincs definiálva, a böngészők visszatérnek a default-src direktívára. Ha egyik sincs definiálva, minden forrás engedélyezett, ami rendkívül nem biztonságos.

Példák:

• script-src 'self';: Csak a dokumentummal azonos eredetű szkriptek betöltését engedélyezi.
• script-src 'self' https://cdn.example.com;: Engedélyezi a szkripteket az azonos eredetű forrásból és a https://cdn.example.com címen található CDN-ről.
• script-src 'self' 'unsafe-inline' 'unsafe-eval';: Rendkívüli óvatossággal használja! Ez engedélyezi az inline szkripteket és az `eval()` használatát, de jelentősen gyengíti a biztonságot. Ideális esetben kerülni kell az 'unsafe-inline' és az 'unsafe-eval' használatát.
• script-src 'self' *.google.com;: Engedélyezi a szkripteket az azonos eredetű forrásból és a google.com bármely aldoménjéről.

default-src

Ez a direktíva visszalépési pontként szolgál más erőforrástípusok számára, ha azok nincsenek explicit módon meghatározva. Például, ha a script-src nincs megadva, a default-src fog vonatkozni a szkriptekre. Jó gyakorlat a default-src meghatározása egy alap biztonsági szint beállításához.

Példa:

            default-src 'self'; script-src 'self' https://cdn.example.com;
            

              
                Copy
              
            
          

Ebben a példában minden erőforrás (képek, stíluslapok, betűtípusok stb.) alapértelmezés szerint csak az azonos eredetről töltődhet be. A szkripteknek azonban engedékenyebb irányelvük van, amely lehetővé teszi őket az azonos eredetről és a megadott CDN-ről is.

base-uri

Ez a direktíva korlátozza azokat az URL-eket, amelyek egy dokumentum <base> címkéjében használhatók. A <base> címke megváltoztathatja az összes relatív URL alap URL-jét egy oldalon, beleértve a szkriptforrásokat is. Ennek korlátozása megakadályozza, hogy egy támadó manipulálja, hova oldódnak fel a relatív szkript elérési utak.

Példa:

            base-uri 'self';
            

              
                Copy
              
            
          

Ez biztosítja, hogy a <base> címke csak az azonos eredetre állítható be.

object-src

Ez a direktíva szabályozza a betölthető beépülő modulok típusait, mint például a Flash, Java appletek stb. Kulcsfontosságú, hogy ezt 'none'-ra állítsuk, mivel a beépülő modulok gyakran elavultak és jelentős biztonsági kockázatot hordoznak. Ha nem használ semmilyen beépülő modult, ennek 'none'-ra állítása erős biztonsági intézkedés.

Példa:

            object-src 'none';
            

              
                Copy
              
            
          

upgrade-insecure-requests

Ez a direktíva arra utasítja a böngészőket, hogy frissítsék a kéréseket HTTPS-re. Ha az oldala támogatja a HTTPS-t, de vegyes tartalommal kapcsolatos problémái lehetnek (pl. erőforrások betöltése HTTP-n keresztül), ez a direktíva segíthet automatikusan átalakítani ezeket a nem biztonságos kéréseket biztonságossá, megelőzve a vegyes tartalomra vonatkozó figyelmeztetéseket és a potenciális sebezhetőségeket.

Példa:

            upgrade-insecure-requests;
            

              
                Copy
              
            
          

report-uri / report-to

Ezek a direktívák létfontosságúak a CSP monitorozásához és hibakereséséhez. Amikor egy böngésző a CSP megsértésével találkozik (pl. egy szkript blokkolásával), egy JSON jelentést küldhet egy megadott URL-re. Ez lehetővé teszi, hogy azonosítsa a potenciális támadásokat vagy a hibás konfigurációkat az irányelvében.

• report-uri: A régebbi, széles körben támogatott direktíva.
• report-to: Az újabb, rugalmasabb direktíva, a Reporting API része.

Példa:

            report-uri /csp-report-endpoint;
report-to /csp-report-endpoint;
            

              
                Copy
              
            
          

Szüksége lesz egy szerveroldali végpontra (pl. /csp-report-endpoint) ezen jelentések fogadásához és feldolgozásához.

A CSP implementálása: Lépésről lépésre

A CSP hatékony implementálása módszeres megközelítést igényel, különösen meglévő alkalmazások esetén, amelyek nagymértékben támaszkodhatnak inline szkriptekre vagy dinamikus kód kiértékelésre.

1. lépés: Kezdjen egy csak jelentő (Report-Only) irányelvvel

Mielőtt érvénybe léptetné a CSP-t és potenciálisan tönkretenné az alkalmazását, kezdje a CSP bevezetését Content-Security-Policy-Report-Only módban. Ez a mód lehetővé teszi a sértések monitorozását anélkül, hogy ténylegesen blokkolná az erőforrásokat. Felbecsülhetetlen értékű annak megértéséhez, hogy az alkalmazása jelenleg mit csinál, és mit kell fehérlistára tenni.

Példa Report-Only fejléc:

            Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Ahogy a jelentések beérkeznek, látni fogja, mely szkriptek vannak blokkolva. Ezután iteratívan módosíthatja az irányelvét a jogos erőforrások engedélyezéséhez.

2. lépés: Elemezze a CSP sértési jelentéseket

Állítsa be a jelentési végpontot és elemezze a beérkező JSON jelentéseket. Keressen mintákat a blokkolt erőforrásokban. A gyakori sértések a következők lehetnek:

• Inline JavaScript (pl. onclick attribútumok, <script>alert('xss')</script>).
• Harmadik féltől származó CDN-ről betöltött JavaScript, amely nem volt fehérlistán.
• Dinamikusan generált szkript tartalom.

3. lépés: Fokozatosan léptesse érvénybe az irányelvet

Miután jól megértette az alkalmazása erőforrás-betöltési mintáit és a jelentések alapján módosította az irányelvét, átválthat a Content-Security-Policy-Report-Only-ról a tényleges Content-Security-Policy fejlécre.

Példa érvényesítő fejléc:

            Content-Security-Policy: default-src 'self'; script-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

4. lépés: Refaktoráljon a nem biztonságos gyakorlatok kiküszöbölése érdekében

A végső cél az 'unsafe-inline', 'unsafe-eval' és a túlzott helyettesítő karakterek (wildcard) eltávolítása a CSP-ből. Ez a JavaScript kódjának refaktorálását igényli:

• Távolítsa el az inline szkripteket: Helyezze át az összes inline JavaScript eseménykezelőt (mint az onclick, onerror) különálló JavaScript fájlokba, és csatolja őket az addEventListener segítségével.
• Távolítsa el az inline eseménykezelőket:

            <button onclick="myFunction()">Click me</button>

// Refaktorálva:
// A JS fájlban:
document.querySelector('button').addEventListener('click', myFunction);
function myFunction() { /* ... */ }
            

              
                Copy
              
            
          

• Kezelje a dinamikus szkriptbetöltést: Ha az alkalmazása dinamikusan tölt be szkripteket, győződjön meg róla, hogy ezek a szkriptek jóváhagyott eredetekből származnak.
• Cserélje le az `eval()` és a `new Function()` használatát: Ezek hatékonyak, de veszélyesek. Ha használja őket, fontolja meg a biztonságosabb alternatívákat vagy a logika refaktorálását. Gyakran a JSON feldolgozása a JSON.parse() segítségével biztonságosabb alternatíva, ha a cél a JSON elemzése volt.
• Használjon nonce-okat vagy hasheket az inline szkriptekhez (ha feltétlenül szükséges): Ha az inline szkriptek refaktorálása kihívást jelent, a CSP mechanizmusokat kínál bizonyos inline szkriptek engedélyezésére anélkül, hogy túlságosan kompromittálná a biztonságot.

Nonce-ok inline szkriptekhez

A nonce (number used once - egyszer használt szám) egy véletlenszerűen generált karakterlánc, amely minden kérésnél egyedi. Beágyazhat egy nonce-t a CSP fejlécébe és az engedélyezni kívánt inline <script> címkékbe.

Példa:

Szerveroldali (nonce generálása):

            // A szerveroldali kódban (pl. Node.js Express-szel):
const crypto = require('crypto');
const nonce = crypto.randomBytes(16).toString('hex');

res.setHeader(
  'Content-Security-Policy',
  `script-src 'self' 'nonce-${nonce}'; object-src 'none'; ...`
);

// A HTML sablonban:
<script nonce="${nonce}">
  // Az Ön inline JavaScript kódja itt
</script>
            

              
                Copy
              
            
          

A böngésző csak azokat az inline szkripteket fogja végrehajtani, amelyeknek megfelelő nonce attribútumuk van.

Hashek inline szkriptekhez

Megadhatja bizonyos inline szkriptblokkok hash-eit is. A böngésző kiszámítja az inline szkriptek hash-ét, és összehasonlítja azt a CSP-ben szereplő hash-ekkel. Ez hasznos statikus inline szkriptek esetén, amelyek nem változnak kérésenként.

Példa:

Ha az inline szkriptje alert('Hello CSP!');, annak SHA256 hash-e J9cQkQn3+tGj9Gv2aL+z0+tJ+K/G2gL7xT0f2j8q0= lenne (ezt egy eszközzel kell kiszámítania).

CSP fejléc:

            Content-Security-Policy: script-src 'self' 'sha256-J9cQkQn3+tGj9Gv2aL+z0+tJ+K/G2gL7xT0f2j8q0=';
            

              
                Copy
              
            
          

Ez kevésbé rugalmas, mint a nonce-ok, de alkalmas lehet bizonyos, változatlan inline kód részletekre.

5. lépés: Folyamatos monitorozás és finomítás

A biztonság egy folyamatos folyamat. Rendszeresen tekintse át a CSP sértési jelentéseit. Ahogy az alkalmazása fejlődik, új harmadik féltől származó szkriptek kerülhetnek bevezetésre, vagy a meglévők frissülhetnek, ami a CSP módosítását teheti szükségessé. Maradjon éber, és szükség szerint frissítse az irányelvét.

Gyakori JavaScript biztonsági buktatók és CSP megoldások

Nézzünk meg néhány gyakori JavaScript biztonsági problémát és azt, hogy a CSP hogyan segít enyhíteni őket:

1. Cross-Site Scripting (XSS) inline szkripteken keresztül

Probléma: Egy támadó rosszindulatú JavaScriptet illeszt be közvetlenül az oldal HTML kódjába, gyakran nem megfelelően szanitizált felhasználói bevitelen keresztül. Ez lehet egy szkript címke vagy egy inline eseménykezelő.

CSP megoldás:

• Tiltsa le az inline szkripteket: Távolítsa el az 'unsafe-inline'-t a script-src-ből.
• Használjon nonce-okat vagy hasheket: Ha az inline szkriptek elkerülhetetlenek, használjon nonce-okat vagy hasheket, hogy csak bizonyos, szándékolt szkripteket engedélyezzen.
• Szanitizálja a felhasználói bevitelt: Ez egy alapvető biztonsági gyakorlat, amely kiegészíti a CSP-t. Mindig szanitizálja és validálja a felhasználóktól származó adatokat, mielőtt megjelenítené azokat az oldalán.

2. XSS harmadik féltől származó szkripteken keresztül

Probléma: Egy legitim harmadik féltől származó szkript (pl. egy CDN-ről, egy analitikai szolgáltatótól vagy egy hirdetési hálózatról) kompromittálódik vagy sebezhetőséget tartalmaz, lehetővé téve a támadók számára, hogy rosszindulatú kódot futtassanak rajta keresztül.

CSP megoldás:

• Legyen szelektív a harmadik féltől származó szkriptekkel: Csak megbízható forrásokból származó szkripteket használjon.
• Pontosítsa a forrásokat: A helyettesítő karakterek, mint a *.example.com helyett, explicit módon sorolja fel a pontos domaineket (pl. scripts.example.com).
• Használjon Subresource Integrity-t (SRI): Bár nem közvetlenül a CSP része, az SRI extra védelmi réteget biztosít. Lehetővé teszi, hogy kriptográfiai hasheket adjon meg a szkript fájljaihoz. A böngésző csak akkor hajtja végre a szkriptet, ha annak integritása megegyezik a megadott hash-sel. Ez megakadályozza, hogy egy kompromittált CDN a szkript rosszindulatú verzióját szolgáltassa.

Példa a CSP és az SRI kombinálására:

HTML:

            <script src="https://trusted.cdn.com/library.js" integrity="sha256-abcdef123456..." crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP fejléc:

            Content-Security-Policy: script-src 'self' https://trusted.cdn.com;
  ...
            

              
                Copy
              
            
          

3. Adatinjekció és DOM manipuláció

Probléma: A támadók megpróbálhatnak olyan adatokat bejuttatni, amelyek manipulálják a DOM-ot, vagy ráveszik a felhasználókat műveletek végrehajtására. Ez néha dinamikusan generált JavaScriptet is magában foglalhat.

CSP megoldás:

• Tiltsa le az 'unsafe-eval'-t: Ez a direktíva megakadályozza, hogy a JavaScript kódot olyan függvényekkel értékeljék ki, mint az eval(), a setTimeout() string argumentumokkal, vagy a new Function(). Ezeket gyakran használják kód dinamikus végrehajtására, ami biztonsági kockázatot jelenthet.
• Szigorú script-src direktívák: Az engedélyezett források explicit megadásával csökkenti a nem szándékolt szkriptvégrehajtás esélyét.

4. Clickjacking

Probléma: A támadók ráveszik a felhasználókat, hogy valami másra kattintsanak, mint amit látnak, általában úgy, hogy legitim elemeket rejtenek el rosszindulatúak mögé. Ezt gyakran úgy érik el, hogy az Ön webhelyét egy iframe-be ágyazzák egy rosszindulatú webhelyen.

CSP megoldás:

• frame-ancestors direktíva: Ez a direktíva szabályozza, hogy mely eredetek ágyazhatják be az Ön oldalát.

Példa:

            Content-Security-Policy: frame-ancestors 'self';
            

              
                Copy
              
            
          

Ez az irányelv megakadályozza, hogy az oldala beágyazódjon egy iframe-be bármely más domainen, kivéve a sajátját. A frame-ancestors 'none'; beállítása megakadályozza, hogy bárhol beágyazódjon.

Globálisan alkalmazható CSP stratégiák

Amikor CSP-t implementál egy globális közönség számára, vegye figyelembe a következőket:

• Tartalomszolgáltató hálózatok (CDN-ek): Sok alkalmazás használ globális CDN-eket a statikus eszközök kiszolgálására. Győződjön meg róla, hogy ezeknek a CDN-eknek a domainjei helyesen vannak fehérlistázva a script-src és más releváns direktívákban. Vegye figyelembe, hogy a különböző régiók különböző CDN peremszervereket használhatnak, de a CSP szempontjából maga a domain számít.
• Nemzetköziesített domainnevek (IDN-ek): Ha az alkalmazása IDN-eket használ, győződjön meg róla, hogy azok helyesen vannak reprezentálva a CSP-ben.
• Harmadik féltől származó szolgáltatások: Az alkalmazások gyakran integrálódnak különböző nemzetközi, harmadik féltől származó szolgáltatásokkal (pl. fizetési átjárók, közösségi média widgetek, analitika). Ezen szolgáltatások mindegyike megkövetelheti bizonyos domainek fehérlistázását. Gondosan kövesse nyomon az összes harmadik féltől származó szkriptforrást.
• Megfelelőség és szabályozások: A különböző régióknak eltérő adatvédelmi szabályozásaik vannak (pl. GDPR Európában, CCPA Kaliforniában). Bár a CSP önmagában nem foglalkozik közvetlenül az adatvédelmi megfeleléssel, ez egy kulcsfontosságú biztonsági intézkedés, amely támogatja a megfelelést az adat kiszivárogtatás megakadályozásával.
• Tesztelés régiók között: Ha az alkalmazásának különböző telepítései vagy konfigurációi vannak a különböző régiókban, tesztelje a CSP implementációját mindegyikben.
• Nyelv és lokalizáció: A CSP direktívák és értékeik szabványosítottak. Magát az irányelvet nem befolyásolja a felhasználó nyelve vagy régiója, de a hivatkozott erőforrások földrajzilag elosztott szervereken lehetnek elhelyezve.

A CSP implementálásának legjobb gyakorlatai

Íme néhány legjobb gyakorlat a robusztus és karbantartható CSP implementáció biztosításához:

1. Kezdje szigorúan és fokozatosan bővítsen: Kezdje a lehető legszigorúbb irányelvvel (pl. default-src 'none';), majd fokozatosan adja hozzá az engedélyezett forrásokat az alkalmazása igényei alapján, a Content-Security-Policy-Report-Only mód széleskörű használatával.
2. Kerülje az 'unsafe-inline' és 'unsafe-eval' használatát: Ezekről ismert, hogy jelentősen gyengítik a biztonsági helyzetét. Prioritásként kezelje a kód refaktorálását ezek kiküszöbölésére.
3. Használjon specifikus forrásokat: A helyettesítő karakterek (*.example.com) helyett részesítse előnyben a specifikus domainneveket, amikor csak lehetséges. A helyettesítő karakterek véletlenül több forrást is engedélyezhetnek a szándékoltnál.
4. Implementáljon jelentéskészítést: Mindig tartalmazzon egy report-uri vagy report-to direktívát. Ez elengedhetetlen a sértések monitorozásához és a potenciális támadások vagy hibás konfigurációk azonosításához.
5. Kombinálja más biztonsági intézkedésekkel: A CSP egy védelmi réteg. A legjobban akkor működik, ha más biztonsági gyakorlatokkal kombinálják, mint például a bemeneti szanitizálás, a kimeneti kódolás, a biztonságos kódolási gyakorlatok és a rendszeres biztonsági auditok.
6. HTTP vs. meta tagek: Bár a CSP beállítható egy meta címkén keresztül (<meta http-equiv="Content-Security-Policy" content="...">), általában ajánlott HTTP fejléceken keresztül beállítani. A HTTP fejlécek jobb védelmet nyújtanak, különösen bizonyos injekciós támadások ellen, amelyek megváltoztathatnák a meta címkét. Továbbá, a HTTP fejlécek feldolgozása az oldal tartalmának renderelése előtt történik, korábbi védelmet biztosítva.
7. Fontolja meg a CSP 3. szintjét: A CSP újabb verziói (mint a 3. szint) fejlettebb funkciókat és rugalmasságot kínálnak. Maradjon naprakész a legújabb specifikációkkal.
8. Teszteljen alaposan: Mielőtt bármilyen CSP módosítást éles környezetbe telepítene, tesztelje azokat alaposan staging környezetekben, különböző böngészőkben és eszközökön.

Eszközök és források

Számos eszköz segíthet a CSP létrehozásában, tesztelésében és kezelésében:

• CSP Evaluator a Google-től: Egy web-alapú eszköz, amely elemzi a webhelye CSP-jét és javaslatokat ad. (https://csp-evaluator.withgoogle.com/)
• CSP direktívák referenciája: A CSP direktívák és magyarázataik átfogó listája. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Using_directives)
• Online CSP generátorok: Eszközök, amelyek segíthetnek egy kiinduló CSP létrehozásában az alkalmazása követelményei alapján.

Következtetés

A Content Security Policy nélkülözhetetlen eszköz minden olyan webfejlesztő számára, aki elkötelezett a biztonságos alkalmazások építése mellett. Azáltal, hogy aprólékosan szabályozza azokat a forrásokat, ahonnan a webalkalmazás betölthet és végrehajthat erőforrásokat, különösen a JavaScriptet, jelentősen csökkentheti az olyan pusztító támadások kockázatát, mint az XSS. Bár a CSP implementálása elsőre ijesztőnek tűnhet, különösen összetett alkalmazások esetében, egy strukturált megközelítés, amely a jelentéskészítéssel kezdődik és fokozatosan szigorítja az irányelvet, biztonságosabb és ellenállóbb webes jelenléthez vezet.

Ne feledje, hogy a biztonság egy folyamatosan fejlődő terület. A Content Security Policy-hoz hasonló elvek megértésével és aktív alkalmazásával proaktív álláspontot képvisel a felhasználók és az adatok védelmében a globális digitális ökoszisztémában. Fogadja el a CSP-t, refaktorálja a kódját, és maradjon éber, hogy egy biztonságosabb webet építsünk mindenki számára.