Content Security Policy pre webové chatboty: Bezpečné povolenie widgetu, API, obrázkov a streamovania

Webový chatbot sa v prehliadači málokedy skladá len z jediného JavaScriptového súboru. Loader otvorí widget, API prijíma správy, odpovede sa vracajú ako stream a profilové obrázky či médiá môžu byť umiestnené na ďalšej doméne. Content Security Policy (CSP) robí tieto cesty viditeľnými a obmedzuje ich: Prehliadač načíta alebo pripojí len to, čo webová stránka výslovne povolí.

Ide o dôležitú druhú vrstvu ochrany proti Cross-Site Scripting a neočakávanému obsahu tretích strán. CSP však neopraví ani nebezpečné API, ani chýbajúcu autentifikáciu, nedostatočnú validáciu vstupov či Prompt Injection. Znižuje možnosti vloženého kódu a obmedzuje rádius chyby. Kľúčová je preto čo najmenšia, otestovaná politika namiesto dlhého zoznamu paušálne schválených domén.

Prečo widgety chatbotov potrebujú osobitné pravidlá CSP

Pri klasickej stránke s obsahom často postačujú zdroje z vlastného pôvodu. Chatbot však po načítaní komunikuje ďalej. connect-src okrem iného riadi fetch(), XMLHttpRequest, EventSource, WebSocket a sendBeacon(). Presne tu prebiehajú správy, streamované odpovede, udalosti spätnej väzby a prípadne telemetria. Ak chýba správny pôvod, widget sa síce zobrazí, ale nedokáže odpovedať.

Ostatné súčasti spadajú pod vlastné direktívy. script-src rozhoduje o loaderi widgetu, img-src o avataroch a obrázkoch v odpovediach, style-src o štýloch a font-src o externých písmach. Widget založený na iframe navyše vyžaduje frame-src. default-src slúži ako záloha pre mnohé výslovne neuvedené typy zdrojov, no nenahrádza vedomú inventarizáciu.

Najdôležitejšia prípravná práca sa preto nekoná v generátore CSP, ale v prehliadači: Otvorte reprezentatívnu stránku, začnite konverzáciu, nechajte vystreamovať dlhú odpoveď, otvorte zdroje, pošlite spätnú väzbu a otestujte chybové aj handoff prípady. V paneli Sieť uvidíte skutočne oslovené origins. Ku každému hostiteľovi zdokumentujte účel, typ zdroja a zodpovednú osobu.

Oddelené povolenie štyroch relevantných dátových ciest

1. Skript widgetu a inicializácia

Získavajte loader pokiaľ možno zo stabilnej, verziovanej adresy. Povolenie ako script-src https: by bolo príliš široké, pretože by povolilo skripty z akejsi koľkoveľkej HTTPS domény. Namiesto toho povoľte presný CDN origin alebo doručujte loader sami. Ak integrácia vyžaduje inline kód, použite nový nonce vygenerovaný pre každú HTTP odpoveď alebo zodpovedajúci hash. 'unsafe-inline' by sa nemal stať rýchlym trvalým riešením.

Nonce patrí len skriptom, ktoré generuje samotná šablóna na strane servera. Middleware, ktorý slepo pridá rovnaký nonce do každého existujúceho tagu script, by dal dôveru aj vloženým tagom. Pre statický, verziovaný skript tretej strany môže dodatočne pomôcť Subresource Integrity; pri často sa meniacich súboroch sa však hash musí kontrolovane aktualizovať.

2. API, Server-Sent Events a WebSocket

Běžné požiadavky POST a odpoveď streamovaná cez fetch() vyžadujú HTTPS API origin v connect-src. Spadajú sem aj Server-Sent Events cez EventSource. Pre WebSocket zadajte výslovne konkrétny wss:// origin. MDN upozorňuje, že 'self' nezahŕňa automatycky schémy WebSocket vo všetkých prehliadačoch. Samostatná direktíva s názvom stream-src neexistuje.

CSP a CORS riešia rôzne úlohy. CSP určuje, kam sa stránka vôbec smie pripojiť; CORS určuje na strane servera, ktoré pôvody smú čítať odpoveď v prehliadači. Schválenie CSP preto neopraví ani chybu CORS, ani vypršaný prístupový token. Same-origin proxy môže politiku zjednodušiť, ale musí naďalej správne spracovávať autentifikáciu, obmedzenia rýchlosti (rate limits), časové limity a odovzdávanie chýb.

3. Obrázky, avatary a vygenerované médiá

V img-src povoľte iba vlastný origin a skutočne použitý origin médií. data: je potrebné len vtedy, ak widget používa malé vstreknuté obrázky; blob: len vtedy, ak prehliadač skutočne vytvára obrázky ako URL typu blob. Každý ďalší zdroj zväčšuje útočnú plochu. Ak sa obrázok najprv načíta cez fetch() a potom sa premení na URL blob, môžu byť ovplyvnené tak connect-src, ako aj img-src.

Neotestujte len štandardného avatara. Skontrolujte náhľadové obrázky, snímky obrazovky zdrojov, prílohy súborov, tmavý režim a zobrazenie chýb pre nedostupné médiá. Parametre URL môžu prenášať dôverné informácie do hásení CSP; koncové body pre reporting by preto mali správy spracovávať dátovo úsporne a neuchovávať ich neobmedzene.

4. iframe, štýly, písma a voliteľné workery

Widget priamo vložený do DOM väčšinou nepotrebuje cudzí frame. Vtedy môže zostatiť frame-src 'none'. Ak však chat beží v iframe, povoľte výhradne jeho presný origin. Od toho treba odlišovať frame-ancestors: Táto direktíva určuje na doručovanom zdroji, ktoré stránky ho smú vkladať. Poskytovateľ widgetu ju preto musí na svojej odpovedi iframe nastaviť zodpovedajúcim spôsobom.

Pri štýloch a písmach platí rovnaký princíp. Povoľte konkrétnych hostiteľov a vyhnite sa 'unsafe-inline', pokiaľ to integrácia umožňuje. Workery alebo zvukové funkcie sa pridávajú len vtedy, ak ich produkt skutočne používa. Preventívne povolenie blob:, celých wildcards domén alebo ľubovoľných zdrojov médií komplikuje neskoršie audity.

Realistický príklad CSP pre chatbot widget

Nasledujúce domény sú zámerne vyhradené ukážkové domény. Nahraďte ich originmi zo svojej vlastnej sieťovej analýzy. Príklad predpokladá externý loader, HTTPS API, oddelený WebSocket pre streamovanie a hostiteľa médií. Nepoužíva žiadne paušálne wildcards:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.chat.example 'nonce-{RANDOM}';
  connect-src 'self' https://api.chat.example wss://stream.chat.example;
  img-src 'self' data: https://media.chat.example;
  style-src 'self' 'nonce-{RANDOM}';
  font-src 'self';
  frame-src 'none';
  worker-src 'self';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'self';
  form-action 'self';
  upgrade-insecure-requests;

{RANDOM} predstavuje silnú hodnotu vygenerovanú nanovo pre každú odpoveď, ktorá je identická v hlavičke aj pri povolených prvkoch script, resp. style. Ak váš widget používa iframe, nahraďte frame-src 'none' presným originom widgetu. Ak používa výhradne HTTPS streamovanie cez fetch() alebo EventSource, origin WebSocket vypadáva. Odstráňte každý zdroj, ktorý po kompletnom teste funkčnosti nie je potrebný.

Politika je praktickým východiskovým bodom, nie univerzálnou šablónou. Moderná prísna CSP môže skripty ešte silnejšie riadiť cez nonces alebo hashe a 'strict-dynamic'. Či je to možné bez problémov s kompatibilitou, závisí od toho, ako loader vytvára ďalšie skripty. Vyjasnite si tento postup s poskytovateľom a otestujte prehliadače, režim súhlasu (consent) a varianty nasadenia (deployment).

Od Report-Only k vynútenej politike

Neovtipujte novú politiku bez kontroly do ostrej prevádzky. Mechanizmus W3C Content-Security-Policy-Report-Only hlási porušenia bez blokovania zdrojov. Takto odhalíte zabudovaných hostiteľov obrázkov, odlišný origin streamovania alebo inline kód skôr, než to ovplyvní používateľov. OWASP odporúča HTTP hlavičku ako preferovaný spôsob doručenia; na rozdiel od prvku meta podporuje aj plný rozsah funkcií.

1. Vytvorenie inventára: Otestujte štart widgetu, prvú správu, dlhú streamovanú odpoveď, zdroje, obrázky, spätnú väzbu, handoff a zmenu súhlasu na viacerých typoch stránok.
2. Nasadenie Report-Only: Začnite s plánovanou úzkou politikou a zbierajte porušenia v obmedzenom časovom období. Odfiltrujte rozšírenia prehliadača a iné nereprodukovateľné rušivé signály.
3. Odôvodnenie každého hostiteľa: Rozširujte politiku iba vtedy, ak konkrétna funkcia produktu vyžaduje daný pôvod. Vyhnite sa používaniu wildcards ako reakcii na jednotlivé hásenia.
4. Automatizované testovanie: Doplňte end-to-end testy, ktoré pošlú správu, počkajú na streamovanie a načítajú obrázok. Zároveň skontrolujte konzolu prehliadača na porušenia CSP.
5. Vynútenie a sledovanie: Aktivujte hlavičku Content-Security-Policy, paralelne sledujte ešte prísnejší variant Report-Only a porovnávajte chybovosť.

Stupňovité nasadenie sa dobre hodí k chatbotu v Shadow Mode. Pre špecifické metriky streamovania pomôže článok o latenciách a timeoutoch. Porušenia CSP by mali pritom platiť ako samostatný signál: Timeout a zablokované spojenie vyžadujú odlišnú analýzu príčin.

Typické chybné konfigurácie

• Príliš široké zoznamy zdrojov: *, https: alebo veľké domény s wildcard robia politiku pohodlnou, ale slabou a ťažko overiteľnou.
• Testuje sa len viditeľný štart: Widget sa otvorí, ale streamovanie, spätná väzba, obrázky alebo handoff zlyhajú až neskôr.
• 'unsafe-inline' zostáva trvalo: Krátkodobá pomôcka pre kompatibilitu sa nenahradí pomocou nonces, hashov ani externého kódu.
• CSP sa zamieňa s riadením prístupu: Politika nenahrádza práva na strane servera, kontrolu relácie (session) ani ochranu pred zneužitím volaní nástrojov.
• Hlásenia obsahujú príliš veľa dát: Úplné URL, query parametre alebo kontext používateľa končia zbytočne dlho v monitorovaní.
• Staging a produkcia sa rozchádzajú: Rôzni hostitelia CDN, API alebo WebSocket sa stanú viditeľnými až po spustení.

Ani úzky script-src neurobí z povoleného tretieho poskytovateľa automaticky bezpečného partnera: Jeho JavaScript beží s možnosťami, ktoré mu vaša stránka dáva. Preto preverujte zmeny poskytovateľov, nové poddomény a aktualizácie loaderov ako ostatné závislosti relevantné pre bezpečnosť. Článok o ochrane pred Prompt Injection dopĺňa túto hranicu prehliadača o pravidlá pre RAG, nástroje a dáta.

Kontrolný zoznam pred spustením

• Sú všetky potrebné origins zo skutočných relácií prehliadača zdokumentované a vecne odôvodnené?
• Povoľuje script-src len loader a kontrolované skripty bez paušálneho 'unsafe-inline'?
• Obsahuje connect-src presné HTTPS, EventSource a prípadne WSS origins?
• Sú zdroje obrázkov, štýlov, písiem, rámcov a workerov oddelené a definované čo najužšie?
• Generujú sa nonces nanovo pre každú odpoveď a nastavujú sa len dôveryhodným prvkom?
• Boli otestované zmeny súhlasu, dlhé streamy, obrázky, chyby, handoff, ako aj desktopové a mobilné zariadenia?
• Boli politika najprv sledovaná v režime Report-Only a následne vynútená ako hlavička?
• Spracovávajú sa správy CSP bez zbytočných osobných alebo dôverných údajov v URL?
• Existuje po aktualizáciách widgetu alebo infraštruktúry automatizovaný regresný test?

Záver

Dobrá CSP pre webové chatboty nie je zberom výnimiek, ale technickou mapou povolených ciest v prehliadači. Oddeľte loader, API, streamovanie, obrázky a zdroje iframe, povoľte presné origins a zaveďte politiku najprv v režime Report-Only. Widget tak zostane plne funkčný, zatiaľ čo neočakávané skripty a spojenia získajú výrazne menší priestor na pôsobenie.

Zdroje

• MDN: Content Security Policy (CSP)
• MDN: Direktíva CSP connect-src
• W3C: Content Security Policy Level 3
• OWASP Cheat Sheet Series: Content Security Policy