Frontend-tietoturvakehotteet: Content Security Policy (CSP) hallintaan

Nykypäivän digitaalisessa maisemassa, jossa verkkosovellukset ovat yhä monimutkaisempia ja toisiinsa kytkettyjä, turvallisuudesta uhkia vastaan on ensisijaisen tärkeää. Vaikka taustaturvallisuus saa usein merkittävää huomiota, myös frontend-tietoturva on yhtä tärkeää. Frontend-tietoturvakehotteet toimivat ensimmäisenä puolustuslinjana, tarjoten mekanismin selaimen ohjaamiseen sen toiminnasta ja käyttäjien suojaamiseen erilaisilta hyökkäyksiltä. Näistä kehotteista Content Security Policy (CSP) erottuu tehokkaana työkaluna laajan riskien pienentämiseen.

Mitä ovat frontend-tietoturvakehotteet?

Frontend-tietoturvakehotteet ovat HTTP-vastauskehotteita, jotka verkkopalvelin lähettää selaimelle. Nämä kehotteet sisältävät ohjeita siitä, miten selaimen tulee käsitellä vastaanotettua sisältöä. Ne auttavat estämään yleisiä hyökkäyksiä, kuten:

• Cross-Site Scripting (XSS): Haitallisten skriptien injektointi luotettuihin verkkosivustoihin.
• Clickjacking: Käyttäjien huijaaminen klikkaamaan jotain muuta kuin mitä he havaitsevat.
• Man-in-the-Middle Attacks: Käyttäjän ja palvelimen välisen viestinnän sieppaaminen.

Joitakin tärkeimpiä frontend-tietoturvakehotteita ovat:

• Content Security Policy (CSP): Määrittää lähteet, joista selain saa ladata resursseja.
• Strict-Transport-Security (HSTS): Pakottaa selaimen käyttämään HTTPS:ää kaikessa verkkosivuston kanssa tapahtuvassa viestinnässä.
• X-Frame-Options: Estää verkkosivuston upottamisen iframeen, lieventäen clickjacking-hyökkäyksiä.
• X-XSS-Protection: Mahdollistaa selaimen sisäänrakennetun XSS-suodattimen. (Huomautus: CSP usein syrjäyttää tämän, mutta se voi silti tarjota puolustuskerroksen).
• Referrer-Policy: Hallitsee pyyntöjen mukana lähetettävän referrer-tiedon määrää.
• Feature-Policy (nykyään Permissions-Policy): Antaa kehittäjille mahdollisuuden ottaa käyttöön ja poistaa käytöstä selainominaisuuksia ja API-rajapintoja.

Syväsukellus Content Security Policyyn (CSP)

Content Security Policy (CSP) on HTTP-vastauskehote, joka hallitsee resursseja, joita käyttäjäagentti saa ladata annetulle sivulle. Se käytännössä valkoissaa hyväksyttyjen sisältölähteiden luetteloa, vähentäen merkittävästi XSS-hyökkäysten riskiä. Määrittämällä selvästi lähteet, joista resurssit, kuten skriptit, tyylitiedostot, kuvat ja fontit, voidaan ladata, CSP tekee hyökkääjille paljon vaikeampaa injektoida haitallista koodia verkkosivustollesi.

Kuinka CSP toimii

CSP toimii tarjoamalla selaimelle luettelon hyväksytyistä lähteistä eri sisältötyypeille. Kun selain kohtaa CSP:n rikkovan resurssin, se estää resurssin ja raportoi rikkomuksesta. Tämä esto-mekanismi estää haitallisen koodin suorittamisen, vaikka hyökkääjä onnistuisikin injektoimaan sen HTML:ään.

CSP-direktiivit

CSP-direktiivit ovat CSP-käytännön ydin. Ne määrittävät sallitut lähteet eri resurssityypeille. Joitakin yleisimmin käytettyjä direktiivejä ovat:

• default-src: Asettaa oletuslähteen kaikille resurssityypeille. Tämä on varadirektiivi, jota käytetään, kun muita tarkempia direktiivejä ei ole määritelty.
• script-src: Määrittää sallitut lähteet JavaScriptille.
• style-src: Määrittää sallitut lähteet CSS-tyylitiedostoille.
• img-src: Määrittää sallitut lähteet kuville.
• font-src: Määrittää sallitut lähteet fonteille.
• media-src: Määrittää sallitut lähteet ääni- ja videosisällölle.
• object-src: Määrittää sallitut lähteet plugineille, kuten Flashille. (Yleensä on parasta olla sallimatta plugineja, jos mahdollista).
• frame-src: Määrittää sallitut lähteet kehyksille (iframe).
• connect-src: Määrittää sallitut lähteet verkkopyynnöille (AJAX, WebSockets).
• base-uri: Rajoittaa URL-osoitteita, joita voidaan käyttää <base>-elementissä.
• form-action: Rajoittaa URL-osoitteita, joihin lomakkeita voidaan lähettää.
• frame-ancestors: Määrittää sallitut vanhemmat, jotka voivat upottaa sivun käyttämällä <frame>, <iframe>, <object>, <embed> tai <applet>. Tämä direktiivi tarjoaa suojaa Clickjackingia vastaan.
• upgrade-insecure-requests: Ohjeistaa käyttäjäagentteja käsittelemään kaikki sivuston turvattomat URL-osoitteet (ladattu HTTP:n kautta) ikään kuin ne olisi korvattu turvallisilla URL-osoitteilla (ladattu HTTPS:n kautta). Tämä direktiivi on tarkoitettu verkkosivustoille, jotka ovat siirtymässä HTTP:stä HTTPS:ään.
• report-uri: Määrittää URL-osoitteen, johon selaimen tulisi lähettää raportteja CSP-rikkomuksista. Vanhentunut, korvattu `report-to`-direktiivillä.
• report-to: Määrittää ryhmän nimen, joka on määritelty `Report-To`-otsakkeessa. Tämä mahdollistaa tarkemman hallinnan raportointiin, mukaan lukien useiden raportointipisteiden määrittäminen.

CSP-lähdearvot

Lähdearvot määrittelevät lähteet, joista resursseja saa ladata. Joitakin yleisiä lähdearvoja ovat:

• *: Sallii sisällön mistä tahansa lähteestä (Vältä tätä tuotannossa!).
• 'self': Sallii sisällön samasta alkuperästä (skeema, isäntä ja portti) kuin suojattu dokumentti.
• 'none': Estää sisällön mistään lähteestä.
• 'unsafe-inline': Sallii inline-JavaScriptin ja CSS:n käytön (Vältä tätä tuotannossa!).
• 'unsafe-eval': Sallii dynaamisen koodin arvioinnin käytön (esim. eval(), Function()) (Vältä tätä tuotannossa!).
• 'strict-dynamic': Määrittää, että merkintään sisältyvälle skriptille nimenomaisesti annettu luottamus, mukana sen nonce tai hash, tulee välittää kaikille skripteille, jotka kyseinen esivanhempi lataa.
• 'unsafe-hashes': Sallii tietyt inline-tapahtumankäsittelijät. Tätä yleensä vältetään sen monimutkaisuuden ja vähäisen hyödyn vuoksi.
• data:: Sallii resurssien lataamisen data-URL-osoitteista (esim. upotetut kuvat). Käytä varoen.
• mediastream:: Sallii `mediastream:` URI-osoitteiden käytön mediasisällön lähteenä.
• blob:: Sallii `blob:` URI-osoitteiden käytön mediasisällön lähteenä.
• filesystem:: Sallii resurssien lataamisen tiedostojärjestelmästä.
• https://example.com: Sallii sisällön tietystä verkkotunnuksesta ja portista.
• *.example.com: Sallii sisällön mistä tahansa example.comin aliverkkotunnuksesta.
• nonce-{random-value}: Sallii skriptit tai tyylit vastaavalla nonce-attribuutilla. Tämä vaatii palvelinpuolen satunnaisen nonce-arvon luomisen jokaiselle pyynnölle.
• sha256-{hash-value}: Sallii skriptit tai tyylit vastaavalla SHA256-, SHA384- tai SHA512-hashilla.

CSP-tilat: Pakota (Enforce) vs. Vain raportoi (Report-Only)

CSP voidaan ottaa käyttöön kahdessa tilassa:

• Pakotustila: Tässä tilassa selain estää kaikki CSP:n rikkovat resurssit. Tämä on suositeltava tila tuotantoympäristöissä. CSP lähetetään `Content-Security-Policy`-otsakkeella.
• Vain raportointitila: Tässä tilassa selain raportoi CSP-rikkomuksista, mutta ei estä resursseja. Tämä on hyödyllistä CSP:n testaamiseen ja arviointiin ennen sen pakottamista. CSP lähetetään `Content-Security-Policy-Report-Only`-otsakkeella.

CSP:n käyttöönotto: Vaiheittainen opas

CSP:n käyttöönotto voi tuntua pelottavalta, mutta noudattamalla jäsenneltyä lähestymistapaa voit tehokkaasti suojata verkkosovelluksesi.

1. Aloita Vain raportointi -käytännöllä

Aloita ottamalla CSP käyttöön vain raportointitilassa. Tämä antaa sinulle mahdollisuuden seurata rikkomuksia häiritsemättä verkkosivustosi toimivuutta. Määritä `report-uri`- tai `report-to`-direktiivi lähettämään rikkomusraportteja nimettyyn päätepisteeseen.

Esimerkkiotsake (Vain raportointi): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Analysoi rikkomusraportit

Analysoi huolellisesti rikkomusraportit tunnistaaksesi, mitkä resurssit estetään ja miksi. Tämä auttaa sinua ymmärtämään verkkosivustosi resurssiriippuvuudet ja tunnistamaan mahdolliset tietoturva-aukot.

Rikkomusraportit lähetetään tyypillisesti JSON-hyötykuormana määritettyyn `report-uri`- tai `report-to`-päätepisteeseen. Nämä raportit sisältävät tietoa rikkomuksesta, kuten estetty URI, rikottu direktiivi ja dokumentti-URI.

3. Hienosäädä CSP-käytäntöä

Rikkomusraporttien perusteella hienosäädä CSP-käytäntöäsi sallimaan lailliset resurssit samalla kun ylläpidät vahvaa tietoturva-asemaa. Lisää erityisiä lähdearvoja estetyille resursseille. Harkitse noncen tai hashien käyttöä inline-skripteille ja tyyleille välttääksesi `"unsafe-inline"`:n käyttöä.

4. Siirry Pakotustilaan

Kun olet varma, että CSP-käytäntösi ei estä laillisia resursseja, siirry pakotustilaan. Tämä estää kaikki jäljellä olevat rikkomukset ja tarjoaa vankan tietoturvakerroksen XSS-hyökkäyksiä vastaan.

Esimerkkiotsake (Pakotettu): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Seuraa ja ylläpidä CSP-käytäntöä

CSP ei ole asenna ja unohda -ratkaisu. On tärkeää seurata jatkuvasti CSP-käytäntöäsi ja päivittää sitä verkkosivustosi kehittyessä ja uusien tietoturvauhkien ilmaantuessa. Tarkista säännöllisesti rikkomusraportteja ja säädä käytäntöä tarvittaessa.

Käytännön CSP-esimerkkejä

Tarkastellaan joitakin käytännön CSP-esimerkkejä eri tilanteisiin:

Esimerkki 1: Perus-CSP yksinkertaiselle verkkosivustolle

Tämä CSP sallii sisällön samasta alkuperästä ja kuvat mistä tahansa lähteestä.

Content-Security-Policy: default-src 'self'; img-src *

Esimerkki 2: CSP tietyillä skripti- ja tyylilähteillä

Tämä CSP sallii skriptit samasta alkuperästä ja tietystä CDN:stä, sekä tyylit samasta alkuperästä ja inline-tyylit.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

Esimerkki 3: CSP noncen kanssa inline-skripteille

Tämä CSP vaatii uniikin noncen jokaiselle inline-skriptille.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

Tärkeää: Nonce-arvo on luotava dynaamisesti palvelimella jokaiselle pyynnölle. Tämä estää hyökkääjiä käyttämästä noncea uudelleen.

Esimerkki 4: CSP rajoittaa Frame Ancestors -asetuksia Clickjackingin estämiseksi

Tämä CSP estää sivun upottamisen iframeen millä tahansa verkkotunnuksella paitsi `https://example.com`.

Content-Security-Policy: frame-ancestors 'self' https://example.com

Esimerkki 5: Rajoittavampi CSP käyttäen 'strict-dynamic' ja varhaista 'self'-arvoa

Tämä CSP hyödyntää `strict-dynamic`-arvoa moderneille selaimille tukien samalla vanhempia selainta, jotka eivät tue sitä. Se sisältää myös `report-uri`-arvon rikkomusten seuraamiseksi.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Muista korvata `{random-nonce}` palvelinpuolella dynaamisesti luodulla nonce-arvolla.

CSP ja Single-Page Applications (SPA)

CSP:n käyttöönotto SPA-sovelluksissa voi olla haastavaa näiden sovellusten dynaamisen luonteen vuoksi. SPA-sovellukset luottavat usein vahvasti JavaScriptiin DOM:n luomiseen ja manipulointiin, mikä voi johtaa CSP-rikkomuksiin, jos sitä ei käsitellä huolellisesti.

Tässä joitakin vinkkejä CSP:n käyttöönottoon SPA-sovelluksissa:

• Vältä `"unsafe-inline"` ja `"unsafe-eval"`: Näitä direktiivejä tulisi välttää aina kun mahdollista SPA-sovelluksissa. Ne heikentävät merkittävästi sovelluksesi tietoturvaa.
• Käytä nonceja tai hasheja: Käytä nonceja tai hasheja inline-skripteille ja tyyleille. Tämä on suositeltava lähestymistapa SPA-sovelluksissa.
• Harkitse Trusted Types -ominaisuutta: Trusted Types on selain-API, joka auttaa estämään DOM-pohjaisia XSS-haavoittuvuuksia. Sitä voidaan käyttää yhdessä CSP:n kanssa tietoturvan parantamiseksi entisestään.
• Käytä CSP-yhteensopivaa kehystä: Jotkut frontend-kehykset (kuten React tietyillä konfiguraatioilla, Angular ja Vue.js) tarjoavat ominaisuuksia, jotka auttavat sinua ottamaan CSP:n käyttöön helpommin.

Muut tärkeät frontend-tietoturvakehotteet

Vaikka CSP on frontend-tietoturvan kulmakivi, muut kehotteet näyttelevät ratkaisevaa roolia kattavan puolustusstrategian tarjoamisessa:

Strict-Transport-Security (HSTS)

Strict-Transport-Security (HSTS) -kehote ohjeistaa selainta käyttämään aina HTTPS:ää verkkosivustoon yhdistettäessä. Tämä estää man-in-the-middle-hyökkäykset, jotka yrittävät alentaa yhteyden HTTP:ksi.

Esimerkkiotsake: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: Määrittää keston (sekunteina), jonka ajan selaimen tulee muistaa käyttää sivustoa vain HTTPS:n kautta. 31536000 sekunnin (1 vuoden) arvoa suositellaan tuotantoympäristöissä.
• includeSubDomains: Osoittaa, että HSTS-käytäntö koskee kaikkia verkkotunnuksen aliverkkotunnuksia.
• preload: Sallii verkkotunnuksen sisällyttämisen HSTS-yhteensopivien verkkotunnusten luetteloon, joka esiladataan selaimiin. Tämä vaatii verkkotunnuksesi lähettämistä Googlen ylläpitämään HSTS-esilatausluetteloon.

X-Frame-Options

X-Frame-Options -kehote estää clickjacking-hyökkäykset kontrolloimalla, voidaanko verkkosivustoa upottaa iframeen.

Esimerkkiotsake: X-Frame-Options: DENY

Mahdolliset arvot:

• DENY: Estää sivun näyttämisen iframessa alkuperästä riippumatta.
• SAMEORIGIN: Sallii sivun näyttämisen iframessa vain, jos iframen alkuperä vastaa sivun alkuperää.
• ALLOW-FROM uri: Sallii sivun näyttämisen iframessa vain, jos iframen alkuperä vastaa määritettyä URI:a. Huomautus: Tämä vaihtoehto on vanhentunut eikä välttämättä ole tuettu kaikissa selaimissa.

Huomautus: CSP:n `frame-ancestors`-direktiivi tarjoaa joustavamman ja tehokkaamman tavan hallita kehystämistä ja on yleensä suositeltavampi kuin `X-Frame-Options`.

X-XSS-Protection

X-XSS-Protection -kehote ottaa käyttöön selaimen sisäänrakennetun XSS-suodattimen. Vaikka CSP on vankempi ratkaisu XSS-hyökkäysten estämiseen, tämä kehote voi tarjota lisäpuolustuskerroksen, erityisesti vanhemmille selaimille, jotka eivät ehkä täysin tue CSP:tä.

Esimerkkiotsake: X-XSS-Protection: 1; mode=block

• 1: Ottaa XSS-suodattimen käyttöön.
• 0: Poistaa XSS-suodattimen käytöstä.
• mode=block: Ohjeistaa selainta estämään sivun, jos XSS-hyökkäys havaitaan.
• report=uri: Määrittää URL-osoitteen, johon selaimen tulisi lähettää raportti, jos XSS-hyökkäys havaitaan.

Referrer-Policy

Referrer-Policy -kehote hallitsee referrer-tiedon määrää, joka lähetetään pyyntöjen mukana. Referrer-tietoa voidaan käyttää käyttäjien seuraamiseen verkkosivustojen välillä, joten sen hallinta voi parantaa käyttäjien yksityisyyttä.

Esimerkkiotsake: Referrer-Policy: strict-origin-when-cross-origin

Joitakin yleisiä arvoja:

• no-referrer: Ei koskaan lähetä Referer-otsaketta.
• no-referrer-when-downgrade: Älä lähetä Referer-otsaketta alkuperäisiin ilman TLS:ää (HTTPS).
• origin: Lähetä vain alkuperä (skeema, isäntä ja portti) Referer-otsakkeessa.
• origin-when-cross-origin: Lähetä alkuperä ristiin-alkuperäisille pyynnöille ja koko URL-osoite saman-alkuperäisille pyynnöille.
• same-origin: Lähetä Referer-otsake saman-alkuperäisille pyynnöille, mutta ei ristiin-alkuperäisille pyynnöille.
• strict-origin: Lähetä vain alkuperä, kun protokollan turvallisuustaso pysyy samana (HTTPS -> HTTPS), mutta älä lähetä otsaketta vähemmän turvalliseen kohteeseen (HTTPS -> HTTP).
• strict-origin-when-cross-origin: Lähetä alkuperä suoritettaessa saman-alkuperäistä pyyntöä. Ristiin-alkuperäisille pyynnöille lähetä alkuperä vain, kun protokollan turvallisuustaso pysyy samana (HTTPS -> HTTPS), mutta älä lähetä otsaketta vähemmän turvalliseen kohteeseen (HTTPS -> HTTP).
• unsafe-url: Lähetä koko URL-osoite Referer-otsakkeessa, alkuperästä riippumatta. Käytä erittäin varoen, sillä tämä voi paljastaa arkaluonteisia tietoja.

Permissions-Policy (entinen Feature-Policy)

Permissions-Policy -kehote (entinen `Feature-Policy`) antaa kehittäjille mahdollisuuden ottaa käyttöön ja poistaa käytöstä selainominaisuuksia ja API-rajapintoja. Tämä voi auttaa vähentämään sovelluksesi hyökkäyspinta-alaa ja parantamaan käyttäjien yksityisyyttä.

Esimerkkiotsake: Permissions-Policy: geolocation=()

Tämä esimerkki poistaa käytöstä maantieteellisen sijainnin API:n verkkosivustolta.

Muita ominaisuuksia, joita voidaan hallita Permissions-Policy-asetuksella, ovat:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

Tietoturvakehotteiden asettaminen eri alustoilla

Tietoturvakehotteiden asettamistapa vaihtelee käyttämäsi verkkopalvelimen tai alustan mukaan. Tässä joitakin yleisiä esimerkkejä:

Apache

Voit asettaa tietoturvakehotteita Apacheen lisäämällä ne `.htaccess`-tiedostoon tai palvelimen konfiguraatiotiedostoon (`httpd.conf`).

Esimerkki `.htaccess`-konfiguraatiosta:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Voit asettaa tietoturvakehotteita Nginxiin lisäämällä ne palvelinlohkoon Nginx-konfiguraatiotiedostossa (`nginx.conf`).

Esimerkki Nginx-konfiguraatiosta:

server {
 listen 443 ssl; 
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Voit asettaa tietoturvakehotteita Node.js:ssä käyttämällä middleware-ohjelmia, kuten Helmet.

Esimerkki Helmetin avulla:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Mukauta CSP tarvittaessa
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare antaa sinun asettaa tietoturvakehotteita käyttämällä Page Rules- tai Transform Rules -ominaisuuksia.

Tietoturvakehotteiden testaaminen

Kun olet ottanut tietoturvakehotteet käyttöön, on tärkeää testata ne varmistaaksesi, että ne toimivat oikein. Useat online-työkalut voivat auttaa sinua analysoimaan verkkosivustosi tietoturvakehotteita:

• SecurityHeaders.com: Yksinkertainen ja tehokas työkalu tietoturvakehotteiden analysointiin.
• Mozilla Observatory: Kattava työkalu verkkosivuston tietoturvan, mukaan lukien tietoturvakehotteiden, testaamiseen.
• WebPageTest.org: Antaa sinun tarkastella HTTP-otsakkeita vesiputouskaaviossa.

Yhteenveto

Frontend-tietoturvakehotteet, erityisesti Content Security Policy (CSP), ovat välttämättömiä verkkosovellusten suojaamisessa erilaisilta hyökkäyksiltä ja käyttäjäturvallisuuden parantamisessa. Huolellisesti toteuttamalla ja ylläpitämällä näitä kehotteita voit merkittävästi vähentää XSS:n, clickjackingin ja muiden tietoturva-aukkojen riskiä. Muista aloittaa vain raportointi -käytännöllä, analysoida rikkomusraportteja, hienosäätää käytäntöä ja sitten siirtyä pakotustilaan. Seuraa ja päivitä tietoturvakehotteitasi säännöllisesti pitääksesi verkkosivustosi turvassa sen kehittyessä ja uusien uhkien ilmaantuessa.

Ottamalla käyttöön ennakoivan lähestymistavan frontend-tietoturvaan voit rakentaa turvallisempia ja luotettavampia verkkosovelluksia, jotka suojaavat käyttäjiäsi ja yritystäsi.