Content Security Policy για Website Chatbots: Ασφαλής έγκριση Widget, API, εικόνων και Streaming

Ένα chatbot ιστότοπου σπάνια αποτελείται στον browser από ένα μόνο αρχείο JavaScript. Ένας loader ανοίγει το widget, ένα API δέχεται τα μηνύματα, οι απαντήσεις επιστρέφουν ως stream και οι εικόνες προφίλ ή τα μέσα ενδέχεται να φιλοξενούνται σε διαφορετικό domain. Η Content Security Policy (CSP) καθιστά αυτές τις διαδρομές ορατές και τις περιορίζει: Ο browser φορτώνει ή συνδέεται μόνο με όσα επιτρέπει ρητά ο ιστότοπος.

Αυτό αποτελεί ένα σημαντικό δεύτερο επίπεδο προστασίας έναντι του Cross-Site Scripting και του ανεπιθύμητου περιεχομένου τρίτων. Ωστόσο, μια CSP δεν διορθώνει ένα μη ασφαλές API, την έλλειψη αυθεντικοποίησης, την ανεπαρκή επικύρωση εισόδου ή το Prompt Injection. Μειώνει τις δυνατότητες εισαγωγής κακόβουλου κώδικα και περιορίζει την εμβέλεια ενός σφάλματος. Επομένως, το κρίσιμο στοιχείο είναι μια όσο το δυνατόν πιο περιορισμένη, δοκιμασμένη πολιτική αντί για μια μακρά λίστα γενικά εγκεκριμένων domains.

Γιατί τα Chatbot Widgets χρειάζονται ειδικούς κανόνες CSP

Σε μια κλασική σελίδα περιεχομένου, οι πόροι από την ίδια την προέλευση (origin) είναι συχνά αρκετοί. Αντίθετα, ένα chatbot συνεχίζει την επικοινωνία μετά τη φόρτωση. Η οδηγία connect-src ελέγχει μεταξύ άλλων τα fetch(), XMLHttpRequest, EventSource, WebSocket και sendBeacon(). Ακριβώς εδώ διακινούνται τα μηνύματα, οι streaming απαντήσεις, τα συμβάντα ανατροφοδότησης (feedback) και ενδεχομένως τα δεδομένα τηλεμετρίας. Εάν λείπει η σωστή προέλευση, το widget θα εμφανιστεί, αλλά δεν θα μπορεί να απαντήσει.

Άλλα στοιχεία εμπίπτουν σε διαφορετικές οδηγίες. Η script-src αποφασίζει για τον loader του widget, η img-src για τα avatars και τις εικόνες απαντήσεων, η style-src για τα stylesheets και η font-src για τις εξωτερικές γραμματοσειρές. Ένα widget που βασίζεται σε iframe χρειάζεται επιπλέον την frame-src. Η default-src χρησιμεύει ως εφεδρεία για πολλούς τύπους πόρων που δεν αναφέρονται ρητά, αλλά δεν αντικαθιστά την εσκεμμένη καταγραφή.

Η πιο σημαντική προεργασία επομένως δεν γίνεται στον γεννήτορα CSP, αλλά στον browser: Ανοίξτε μια αντιπροσωπευτική σελίδα, ξεκινήστε μια συνομιλία, αφήστε μια μακρά απάντηση να κάνει stream, ανοίξτε πηγές, στείλτε feedback και δοκιμάστε περιπτώσεις σφαλμάτων καθώς και handoff. Στο Network Panel θα δείτε τα origins που πραγματικά καλούνται. Τεκμηριώστε για κάθε host τον σκοπό, τον τύπο πόρου και έναν υπεύθυνο.

Έγκριση των τεσσάρων σχετικών διαδρομών δεδομένων ξεχωριστά

1. Script του Widget και αρχικοποίηση

Λάβετε τον loader κατά προτίμηση από μια σταθερή διεύθυνση με διαχείριση εκδόσεων (versioned). Μια έγκριση όπως script-src https: θα ήταν πολύ ευρεία, καθώς θα επέτρεπε scripts από οποιοδήποτε HTTPS domain. Αντίθετα, επιτρέψτε το ακριβές CDN origin ή διαθέστε τον loader από τον δικό σας διακομιστή. Εάν η ενσωμάτωση απαιτεί inline κώδικα, χρησιμοποιήστε ένα nonce που παράγεται εκ νέου ανά απάντηση HTTP ή ένα κατάλληλο hash. Το 'unsafe-inline' δεν πρέπει να γίνει μια γρήγορη μόνιμη λύση.

Ένα nonce ανήκει μόνο σε scripts που παράγει το ίδιο το server-side template. Ένα middleware που προσθέτει τυφλά το ίδιο nonce σε κάθε υπάρχον script tag θα παρείχε εμπιστοσύνη και σε εισαγόμενα (injected) tags. Για ένα στατικό εξωτερικό script με συγκεκριμένη έκδοση, το Subresource Integrity μπορεί να βοηθήσει επιπλέον· σε αρχεία που αλλάζουν συχνά, ωστόσο, το hash πρέπει να ενημερώνεται ελεγχόμενα.

2. API, Server-Sent Events και WebSocket

Τα κανονικά αιτήματα POST και μια απάντηση που λαμβάνεται μέσω streaming με fetch() απαιτούν το HTTPS API origin στην connect-src. Τα Server-Sent Events μέσω EventSource εμπίπτουν επίσης εδώ. Για ένα WebSocket, καταχωρίστε ρητά το συγκεκριμένο wss:// origin. Το MDN επισημαίνει ότι το 'self' δεν περιλαμβάνει αυτόματα τα σχήματα WebSocket σε όλους τους browsers. Δεν υπάρχει ειδική οδηγία με το όνομα stream-src.

Η CSP και το CORS επιλύουν διαφορετικά ζητήματα. Η CSP καθορίζει πού επιτρέπεται γενικά να συνδεθεί η σελίδα· το CORS καθορίζει στην πλευρά του διακομιστή ποιες προελεύσεις επιτρέπεται να διαβάσουν μια απάντηση στον browser. Επομένως, μια έγκριση CSP δεν διορθώνει ούτε ένα σφάλμα CORS ούτε ένα ληγμένο token πρόσβασης. Ένας Same-Origin proxy μπορεί να απλοποιήσει την πολιτική, αλλά πρέπει να συνεχίσει να διαχειρίζεται σωστά την αυθεντικοποίηση, τα όρια ρυθμού (rate limits), τα timeouts και τη διαβίβαση σφαλμάτων.

3. Εικόνες, avatars και παραγόμενα μέσα

Επιτρέψτε στην img-src μόνο τη δική σας προέλευση και το origin μέσων που πραγματικά χρησιμοποιείται. Το data: είναι απαραίτητο μόνο εάν το widget χρησιμοποιεί μικρές ενσωματωμένες εικόνες· το blob: μόνο εάν ο browser δημιουργεί εικόνες ως Blob URL. Κάθε επιπλέον πηγή αυξάνει την επιφάνεια επίθεσης. Εάν μια εικόνα φορτώνεται πρώτα μέσω fetch() και στη συνέχεια μετατρέπεται σε Blob URL, ενδέχεται να επηρεαστούν τόσο η connect-src όσο και η img-src.

Μην δοκιμάζετε μόνο το προεπιλεγμένο avatar. Ελέγξτε τις εικόνες προεπισκόπησης, τα screenshots πηγών, τα συνημμένα αρχεία, το Dark Mode και την εμφάνιση σφαλμάτων για μη διαθέσιμα μέσα. Οι παράμετροι URL μπορούν να μεταφέρουν εμπιστευτικές πληροφορίες σε αναφορές CSP· επομένως, τα endpoints αναφοράς πρέπει να επεξεργάζονται τις αναφορές με φειδώ ως προς τα δεδομένα και να μην τις διατηρούν επ' αόριστον.

4. iframe, Styles, Fonts και προαιρετικά Workers

Ένα widget που ενσωματώνεται απευθείας στο DOM συνήθως δεν χρειάζεται εξωτερικό frame. Σε αυτή την περίπτωση, η frame-src 'none' μπορεί να παραμείνει. Εάν η συνομιλία εκτελείται σε iframe, επιτρέψτε αποκλειστικά το ακριβές origin του. Διαφορετική είναι η οδηγία frame-ancestors: Αυτή η οδηγία καθορίζει στον παρεχόμενο πόρο ποιες σελίδες επιτρέπεται να τον ενσωματώσουν. Ο πάροχος του widget πρέπει επομένως να τη ρυθμίσει κατάλληλα στην απάντηση του iframe του.

Η ίδια αρχή ισχύει για τα Styles και τα Fonts. Επιτρέψτε συγκεκριμένους hosts και αποφύγετε το 'unsafe-inline', εφόσον το επιτρέπει η ενσωμάτωση. Οι λειτουργίες Worker ή ήχου προστίθενται μόνο εάν το προϊόν τις χρησιμοποιεί πραγματικά. Η προληπτική έγκριση του blob:, ολόκληρων domains με wildcard ή τυχαίων πηγών μέσων δυσχεραίνει τους μεταγενέστερους ελέγχους (audits).

Ένα ρεαλιστικό παράδειγμα CSP για ένα Chatbot Widget

Τα ακόλουθα domains είναι εσκεμμένα δεσμευμένα παραδείγματα. Αντικαταστήστε τα με τα origins από τη δική σας ανάλυση δικτύου. Το παράδειγμα υποθέτει έναν εξωτερικό loader, ένα HTTPS API, ένα ξεχωριστό WebSocket για streaming και έναν host μέσων. Δεν χρησιμοποιεί γενικά 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} αντιπροσωπεύει μια ισχυρή τιμή, παραγόμενη εκ νέου ανά απάντηση, η οποία είναι πανομοιότυπη στην επικεφαλίδα (header) και στα επιτρεπόμενα στοιχεία script ή style. Εάν το widget σας χρησιμοποιεί iframe, αντικαταστήστε το frame-src 'none' με το ακριβές origin του widget. Εάν χρησιμοποιεί αποκλειστικά HTTPS streaming μέσω fetch() ή EventSource, το WebSocket origin παραλείπεται. Αφαιρέστε κάθε πηγή που δεν είναι απαραίτητη μετά από πλήρη δοκιμή λειτουργικότητας.

Η πολιτική αυτή αποτελεί ένα πρακτικό σημείο εκκίνησης, όχι ένα καθολικό πρότυπο. Μια σύγχρονη αυστηρή CSP μπορεί να ελέγξει τα scripts ακόμη πιο αυστηρά μέσω nonces ή hashes και του 'strict-dynamic'. Το αν αυτό είναι εφικτό χωρίς προβλήματα συμβατότητας εξαρτάται από το πώς ο loader δημιουργεί επιπλέον scripts. Διευκρινίστε αυτή τη διαδικασία με τον πάροχο και δοκιμάστε browsers, consent mode και παραλλαγές deployment.

Από το Report-Only στην επιβαλλόμενη πολιτική

Μην ενεργοποιείτε μια νέα πολιτική στην παραγωγή χωρίς έλεγχο. Ο μηχανισμός W3C Content-Security-Policy-Report-Only αναφέρει παραβιάσεις χωρίς να μπλοκάρει πόρους. Έτσι εντοπίζετε ξεχασμένους hosts εικόνων, διαφορετικό streaming origin ή inline κώδικα πριν επηρεαστούν οι χρήστες. Το OWASP συνιστά την επικεφαλίδα HTTP ως προτιμώμενο τρόπο παράδοσης· σε αντίθεση με το στοιχεία meta, υποστηρίζει το πλήρες εύρος λειτουργιών.

1. Δημιουργήστε καταγραφή (inventory): Δοκιμάστε την εκκίνηση του widget, το πρώτο μήνυμα, τη μακρά απάντηση streaming, τις πηγές, τις εικόνες, το feedback, το handoff και τις αλλαγές consent σε πολλαπλούς τύπους σελίδων.
2. Εφαρμόστε το Report-Only: Ξεκινήστε με την σχεδιαζόμενη περιοριστική πολιτική και συλλέξτε παραβιάσεις για ένα καθορισμένο χρονικό διάστημα. Φιλτράρετε επεκτάσεις browser και άλλα μη αναπαραγώγιμα σήματα θορύβου.
3. Αιτιολογήστε κάθε host: Επεκτείνετε την πολιτική μόνο εάν μια συγκεκριμένη λειτουργία του προϊόντος απαιτεί την προέλευση. Αποφύγετε τα wildcards ως αντίδραση σε μεμονωμένες αναφορές.
4. Δοκιμάστε αυτοματοποιημένα: Προσθέστε end-to-end δοκιμές που στέλνουν ένα μήνυμα, περιμένουν το streaming και φορτώνουν μια εικόνα. Παράλληλα, ελέγχετε την κοσόλα του browser για παραβιάσεις CSP.
5. Επιβάλετε και παρακολουθήστε: Ενεργοποιήστε την επικεφαλίδα Content-Security-Policy, διατηρήστε παράλληλα μια ακόμη πιο αυστηρή παραλλαγή Report-Only και συγκρίνετε τα ποσοστά σφαλμάτων.

Μια σταδιακή εφαρμογή ταιριάζει εξαιρετικά με ένα Chatbot σε Shadow Mode. Για μετρήσεις ειδικές για το streaming, βοηθά το άρθρο σχετικά με τα προϋπολογισμούς λαμβανόμενης καθυστέρησης (latency budgets) και τα timeouts. Οι παραβιάσεις CSP θα πρέπει να θεωρούνται ως ξεχωριστό σήμα: Ένα timeout και μια μπλοκαρισμένη σύνδεση απαιτούν διαφορετική ανάλυση αιτίων.

Συνήθεις λανθασμένες ρυθμίσεις

• Πολύ ευρείες λίστες πηγών: Το *, το https: ή μεγάλα domains με wildcard جعلουν την πολιτική βολική, αλλά αδύναμη και δύσκολα ελέγξιμη.
• Δοκιμάζεται μόνο η ορατή εκκίνηση: Το widget ανοίγει, αλλά το streaming, το feedback, οι εικόνες ή το handoff αποτυγχάνουν αργότερα.
• Το 'unsafe-inline' παραμένει μόνιμα: Μια βραχυπρόθεσμη βοήθεια συμβατότητας δεν αντικαθίσταται από nonces, hashes ή εξωτερικό κώδικα.
• Η CSP συγχέεται με τον έλεγχο πρόσβασης: Η πολιτική δεν αντικαθιστά τα δικαιώματα στην πλευρά του διακομιστή, τον έλεγχο συνεδρίας (session) ούτε την προστασία από καταχρηστικές κλήσεις εργαλείων.
• Οι αναφορές περιέχουν υπερβολικά δεδομένα: Πλήρη URLs, παράμετροι query ή πλαίσιο χρήστη καταλήγουν άσκοπα για μεγάλο διάστημα στο monitoring.
• Απόκλιση μεταξύ Staging και Παραγωγής: Διαφορετικοί hosts CDN, API ή WebSocket γίνονται ορατοί μόνο μετά το go-live.

Ακόμη και μια περιορισμένη script-src δεν καθιστά αυτόματα ασφαλή έναν εγκεκριμένο τρίτο πάροχο: Η JavaScript του εκτελείται με τις δυνατότητες που της δίνει η σελίδα σας. Επομένως, ελέγχετε τις αλλαγές παρόχων, τα νέα subdomains και τις ενημερώσεις loaders όπως κάθε άλλη εξάρτηση σχετική με την ασφάλεια. Το άρθρο για την προστασία από Prompt Injection συμπληρώνει αυτό το όριο του browser με κανόνες για RAG, εργαλεία και δεδομένα.

Λίστα ελέγχου πριν το Go-live

• Έχουν τεκμηριωθεί και αιτιολογηθεί τεχνικά όλες οι απαιτούμενες προελεύσεις (origins) από πραγματικές συνεδρίες browser;
• Επιτρέπει η script-src μόνο τον loader και ελεγχόμενα scripts, χωρίς γενικό 'unsafe-inline';
• Περιλαμβάνει η connect-src τα ακριβή HTTPS, EventSource και ενδεχομένως WSS origins;
• Είναι οι πηγές εικόνων, styles, γραμματοσειρών, frames και workers διαχωρισμένες και ορισμένες όσο το δυνατόν πιο περιοριστικά;
• Δημιουργούνται τα nonces εκ νέου ανά απάντηση και τοποθετούνται μόνο σε έμπιστα στοιχεία;
• Έχουν δοκιμαστεί αλλαγές consent, μακρά streams, εικόνες, σφάλματα, handoff καθώς και συσκευές desktop και mobile;
• Παρακολουθήθηκε η πολιτική αρχικά σε λειτουργία Report-Only και στη συνέχεια επιβλήθηκε ως επικεφαλίδα (header);
• Επεξεργάζονται οι αναφορές CSP χωρίς περιττά προσωπικά ή εμπιστευτικά δεδομένα URL;
• Υπάρχει αυτοματοποιημένος έλεγχος παλινδρόμησης (regression test) μετά από ενημερώσεις του widget ή της υποδομής;

Συμπέρασμα

Μια καλή CSP για chatbots ιστότοπου δεν είναι μια συλλογή εξαιρέσεων, αλλά ένας τεχνικός χάρτης των επιτρεπόμενων διαδρομών του browser. Διαχωρίστε τον loader, το API, το streaming, τις εικόνες και τους πόρους iframe, επιτρέψτε ακριβή origins και εφαρμόστε την πολιτική πρώτα σε λειτουργία Report-Only. Έτσι, το widget παραμένει λειτουργικό, ενώ τα μη αναμενόμενα scripts και συνδέσεις αποκτούν σημαντικά λιγότερα περιθώρια ελιγμών.

Πηγές

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