Content Security Policy σε ιστοσελίδες: γιατί δεν αρκεί να γράφετε ασφαλή κώδικα
Η ασφάλεια μιας ιστοσελίδας δεν τελειώνει στο login, στο HTTPS ή στο server-side validation. Ένα σοβαρό site ή web app χρειάζεται και σωστά browser-level μέτρα προστασίας. Ένα από τα πιο σημαντικά είναι το Content Security Policy, γνωστό ως CSP.
Το CSP είναι security header που λέει στον browser από πού επιτρέπεται να φορτώσει scripts, styles, εικόνες, fonts, iframes και άλλα resources. Αν εφαρμοστεί σωστά, μειώνει το ρίσκο από XSS και από κακόβουλο ή ανεπιθύμητο τρίτο κώδικα.
Δεν αντικαθιστά τον ασφαλή κώδικα. Λειτουργεί ως επιπλέον επίπεδο άμυνας.
Τι πρόβλημα λύνει το CSP
Σε μια σύγχρονη ιστοσελίδα φορτώνονται πολλά πράγματα:
- JavaScript της εφαρμογής
- analytics scripts
- pixels διαφήμισης
- chat widgets
- payment scripts
- fonts
- videos
- iframes
- third-party integrations
Αν ένας εισβολέας καταφέρει να εισαγάγει κακόβουλο script, ή αν φορτωθεί script από λάθος πηγή, το CSP μπορεί να περιορίσει τι επιτρέπεται να εκτελεστεί.
Για παράδειγμα, μια πολιτική μπορεί να λέει ότι scripts επιτρέπονται μόνο από το δικό σας domain και από συγκεκριμένες trusted υπηρεσίες. Ό,τι άλλο μπλοκάρεται.
Γιατί δεν μπαίνει πρόχειρα
Ένα CSP που γράφεται γρήγορα μπορεί να σπάσει κανονικές λειτουργίες.
Μπορεί να επηρεάσει:
- Google Analytics
- Tag Manager
- payment providers
- embedded maps
- chat widgets
- inline scripts
- styles από UI libraries
- εικόνες από CDN
- fonts από τρίτες πηγές
Γι' αυτό η σωστή εφαρμογή συνήθως ξεκινά με report-only mode. Εκεί ο browser αναφέρει τι θα μπλοκαριζόταν, χωρίς να το μπλοκάρει ακόμη. Έτσι μπορείτε να δείτε πραγματικά dependencies πριν ενεργοποιήσετε αυστηρή πολιτική.
Βασικές οδηγίες CSP
Ένα CSP μπορεί να περιλαμβάνει directives όπως:
- default-src
- script-src
- style-src
- img-src
- font-src
- connect-src
- frame-src
- object-src
- base-uri
- form-action
Δεν υπάρχει μία πολιτική που ταιριάζει σε όλους. Ένα απλό εταιρικό site, ένα e-shop με payments και ένα SaaS portal έχουν διαφορετικές ανάγκες.
Το σημαντικό είναι να αποφεύγετε υπερβολικά χαλαρές επιλογές χωρίς λόγο, όπως να επιτρέπετε τα πάντα από παντού. Αν το policy καταλήγει να λέει ουσιαστικά «όλα επιτρέπονται», δεν προσφέρει πολλά.
CSP και third-party scripts
Τα third-party scripts είναι χρήσιμα, αλλά αυξάνουν την επιφάνεια ρίσκου. Κάθε pixel, widget ή external script είναι κώδικας που τρέχει στον browser του χρήστη.
Πριν επιτρέψετε μια πηγή στο CSP, ρωτήστε:
- είναι απαραίτητη για τη λειτουργία ή τη μέτρηση;
- φορτώνεται σε όλες τις σελίδες ή μόνο όπου χρειάζεται;
- στέλνει δεδομένα σε εξωτερικά domains;
- υπάρχει εναλλακτική server-side ή πιο περιορισμένη υλοποίηση;
- ποιος έχει ευθύνη αν το script αλλάξει συμπεριφορά;
Αυτό είναι ιδιαίτερα σημαντικό σε e-shop, φόρμες leads και portals όπου οι χρήστες εισάγουν δεδομένα.
Άλλα security headers που συνδυάζονται
Το CSP είναι ένα κομμάτι της εικόνας. Συνήθως συνδυάζεται με headers όπως:
- Strict-Transport-Security
- X-Content-Type-Options
- Referrer-Policy
- Permissions-Policy
- frame-ancestors μέσα στο CSP
Τα headers αυτά βοηθούν τον browser να συμπεριφέρεται πιο αυστηρά και πιο προβλέψιμα.
Πώς το κάνει η Ai Foundry
Στην Ai Foundry δεν βλέπουμε τα security headers ως checkbox στο τέλος. Σε ιστοσελίδες, e-shop, portals και custom εφαρμογές εξετάζουμε από νωρίς ποιες εξωτερικές υπηρεσίες χρειάζονται, ποια scripts φορτώνονται, πού υπάρχουν φόρμες ή ευαίσθητα flows και ποια πολιτική μπορεί να εφαρμοστεί χωρίς να σπάσει η εμπειρία.
Η πρακτική προσέγγιση είναι staged: πρώτα καταγραφή, μετά report-only, μετά σταδιακή αυστηροποίηση. Έτσι η ασφάλεια βελτιώνεται με έλεγχο, όχι με ρύθμιση που μπορεί να ρίξει analytics, checkout ή integrations.
Checklist για CSP
Πριν ενεργοποιήσετε CSP, ελέγξτε:
- ποια scripts φορτώνονται σε κάθε σελίδα
- αν υπάρχουν inline scripts που μπορούν να αφαιρεθούν
- ποια domains χρειάζονται για analytics, pixels και payments
- αν υπάρχει report-only περίοδος
- αν τα reports παρακολουθούνται
- αν το policy διαφέρει ανά περιβάλλον
- αν τα iframes περιορίζονται σωστά
- αν τα forms στέλνουν μόνο στα αναμενόμενα endpoints
- αν το policy δοκιμάστηκε σε checkout και φόρμες
Συμπέρασμα
Το Content Security Policy δεν κάνει από μόνο του μια εφαρμογή ασφαλή. Μειώνει όμως σημαντικά το περιθώριο ζημιάς όταν κάτι πάει στραβά.
Για σοβαρές ιστοσελίδες, e-shop και web apps, το CSP και τα security headers πρέπει να σχεδιάζονται μαζί με την αρχιτεκτονική, τα third-party scripts και τα user flows.
Πηγές για περαιτέρω ανάγνωση: MDN Content Security Policy, OWASP Content Security Policy Cheat Sheet, OWASP Secure Headers Project.