Τι μπορεί πραγματικά να περιορίσει το header Permissions-Policy

Η σύντομη εκδοχή

Το Permissions-Policy είναι ένα HTTP response header που επιτρέπει σε έναν ιστότοπο να περιορίζει την πρόσβαση σε ορισμένες δυνατότητες του browser: κάμερα, μικρόφωνο, γεωεντοπισμό, πλήρη οθόνη, πληρωμές, αισθητήρες και μια μεγάλη λίστα μικρότερων APIs.

Δεν είναι μια γενική ασπίδα ιδιωτικότητας. Δεν θα σταματήσει κάθε μορφή tracking, δεν θα μπλοκάρει cookies, δεν θα αποτρέψει network requests και δεν θα κάνει ασφαλές το third-party JavaScript. Αυτό που μπορεί να κάνει καλά είναι πιο στενό και παραμένει πολύτιμο: να μειώσει τις δυνατότητες του browser που είναι διαθέσιμες στις δικές σας σελίδες και στα ενσωματωμένα frames.

Αυτό έχει σημασία επειδή οι σύγχρονοι ιστότοποι συντίθενται από analytics snippets, media embeds, chat widgets, consent managers, advertising scripts, χάρτες, ροές πληρωμών και εσωτερικά πειράματα. Τα περισσότερα από αυτά τα components δεν χρειάζονται πρόσβαση σε ισχυρά device APIs. Μια καλή πολιτική το κάνει αυτό σαφές.

Αν ήδη ελέγχετε headers στην παραγωγή, συνδυάστε αυτήν τη δουλειά με έναν άμεσο έλεγχο του πραγματικού response. Ο οδηγός μας για το debugging redirects και HTTP headers στην παραγωγή καλύπτει τη συνήθεια που έχει σημασία εδώ: ελέγχετε τι λαμβάνει πραγματικά ο browser, όχι τι λέει το configuration file σας ότι πρέπει να συμβεί.

Τι ελέγχει το Permissions-Policy

Το header ελέγχει την πρόσβαση σε ονομασμένες δυνατότητες του browser. Η ακριβής λίστα αλλάζει με τον χρόνο επειδή αλλάζουν τα browser APIs, αλλά συνηθισμένες οδηγίες περιλαμβάνουν:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort σε παλαιότερες συζητήσεις, πλέον κυρίως ιστορικό

Μια οδηγία μπορεί να επιτρέψει μια δυνατότητα σε κανέναν, στην τρέχουσα προέλευση ή σε επιλεγμένες προελεύσεις. Για παράδειγμα:

Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Αυτό σημαίνει ότι η κάμερα και το μικρόφωνο απενεργοποιούνται για το document και τα ένθετα browsing contexts του, ενώ ο γεωεντοπισμός επιτρέπεται μόνο για την ίδια προέλευση.

Ένα πιο επιτρεπτικό παράδειγμα:

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

Αυτό επιτρέπει στη δική σας προέλευση και σε έναν ονομασμένο πάροχο χαρτών να χρησιμοποιούν γεωεντοπισμό, και στη δική σας προέλευση μαζί με έναν πάροχο βίντεο να ζητούν πλήρη οθόνη.

Η πολιτική αξιολογείται από τον browser. Αν μια δυνατότητα δεν επιτρέπεται, το JavaScript που χρησιμοποιεί αυτό το API θα πρέπει να αποτύχει ή να συμπεριφερθεί σαν να μην είναι διαθέσιμο. Ο ακριβής τρόπος αποτυχίας εξαρτάται από το API. Μερικές φορές ένα promise απορρίπτεται. Μερικές φορές μια δυνατότητα απλώς δεν φαίνεται χρησιμοποιήσιμη.

Τι μπορεί να περιορίσει στις δικές σας σελίδες

Σε first-party σελίδες, το Permissions-Policy είναι πιο χρήσιμο ως προστατευτικό όριο. Μειώνει το εύρος επίδρασης από τυχαίο ή απρόσμενο κώδικα.

Μια marketing σελίδα, για παράδειγμα, πιθανότατα δεν χρειάζεται μικρόφωνο, κάμερα, Bluetooth, USB, αισθητήρες κίνησης ή payment APIs. Μπορείτε να αρνηθείτε αυτές τις δυνατότητες καθολικά:

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

Αυτό δεν κάνει κάθε script στη σελίδα αξιόπιστο. Σημαίνει όμως ότι αν ένα tag manager experiment, ένα compromised dependency ή ένα pasted widget προσπαθήσει να καλέσει ένα περιορισμένο API, ο browser δεν θα πρέπει να του δώσει πρόσβαση.

Για ομάδες με πολλούς contributors, αυτό είναι μια χρήσιμη προεπιλογή. Μετακινεί τη συζήτηση από την ασαφή εμπιστοσύνη στη ρητή δυνατότητα. Αν μια μελλοντική λειτουργία χρειάζεται πραγματικά την κάμερα, κάποιος πρέπει να αλλάξει την πολιτική και να εξηγήσει γιατί.

Αυτό είναι το σωστό είδος τριβής.

Τι μπορεί να περιορίσει σε iframes

Το header γίνεται ιδιαίτερα χρήσιμο γύρω από ενσωματωμένο περιεχόμενο.

Οι browsers ήδη αντιμετωπίζουν τα iframes ως ξεχωριστά browsing contexts, αλλά ενσωματωμένο third-party περιεχόμενο μπορεί ακόμη να ζητήσει ισχυρές δυνατότητες αν επιτρέπεται από την πολιτική και τα iframe attributes. Το Permissions-Policy επιτρέπει στη γονική σελίδα να ορίσει ένα ανώτατο όριο.

Για παράδειγμα, αν η σελίδα σας ενσωματώνει ένα video player, ένα support widget και έναν χάρτη, μπορείτε να αποφύγετε να δώσετε σε κάθε frame πρόσβαση σε κάθε δυνατότητα. Μπορείτε να επιτρέψετε πλήρη οθόνη μόνο για το video frame και γεωεντοπισμό μόνο για το map frame.

Υπάρχουν δύο επίπεδα που πρέπει να κατανοήσετε:

1. Το HTTP Permissions-Policy header ορίζει πολιτική για το document.
2. Το iframe allow attribute μπορεί να αναθέσει συγκεκριμένες δυνατότητες σε ένα frame, αλλά μόνο μέσα στα όρια που επιτρέπει η γονική πολιτική.

Ένα απλό iframe μπορεί να μοιάζει έτσι:

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

Αν το header σας αρνείται πλήρως την πλήρη οθόνη, το iframe attribute δεν μπορεί να παρακάμψει αυτήν την άρνηση. Αν το header σας επιτρέπει την πλήρη οθόνη για αυτήν την προέλευση, το iframe attribute μπορεί να την αναθέσει.

Αυτή η ιεραρχία είναι ένας λόγος που αξίζει να χρησιμοποιείτε το header. Δίνει στις platform ή security ομάδες έναν τρόπο να ορίζουν όρια σε επίπεδο ιστότοπου, ενώ εξακολουθεί να επιτρέπει στις product ομάδες να ενεργοποιούν συγκεκριμένα embeds όπου χρειάζεται.

Τι δεν μπορεί να περιορίσει

Εδώ είναι που οι ομάδες μερικές φορές υπερεκτιμούν το header.

Το Permissions-Policy δεν αντικαθιστά ένα content security policy. Δεν αποφασίζει ποια scripts μπορούν να φορτωθούν. Δεν σταματά ένα script από το να στέλνει δεδομένα μέσω του δικτύου. Δεν καθαρίζει HTML. Δεν αποτρέπει XSS. Δεν μπλοκάρει form spam. Αν το πρόβλημα είναι η κατάχρηση φορμών, ξεκινήστε με τους μηχανισμούς που περιγράφονται στο γιατί η φόρμα επικοινωνίας σας είναι η μεγαλύτερη ευθύνη σας για spam, όχι με αυτό το header.

Επίσης δεν αντικαθιστά τη διακυβέρνηση των cookies. Cookies, local storage, consent, third-party embeds και browser tracking protections είναι ξεχωριστά ζητήματα. Αν εξετάζετε ευρύτερα τους ελέγχους ιδιωτικότητας, το τοπίο των cookies αξίζει τη δική του ανασκόπηση· οι πρακτικές αλλαγές καλύπτονται στο τι άλλαξε για τα cookies το 2026 και τι να κάνετε γι’ αυτό.

Το σημαντικότερο είναι ότι το Permissions-Policy δεν κάνει ιδιωτικό το third-party JavaScript. Αν φορτώσετε ένα third-party script στη first-party σελίδα σας, γενικά εκτελείται με τα privileges της σελίδας σας, υπό τους υπόλοιπους περιορισμούς του browser και τα security headers σας. Το να αρνείστε την πρόσβαση στην κάμερα είναι καλό. Δεν σταματά αυτό το script από το να διαβάζει DOM content, να παρατηρεί ενέργειες χρηστών ή να κάνει επιτρεπόμενα network requests.

Γι’ αυτό χρειάζεστε διαφορετικούς ελέγχους: προσεκτική επιλογή vendors, CSP, sandboxed iframes, Subresource Integrity όπου εφαρμόζεται, ελαχιστοποίηση δεδομένων και βαρετούς αλλά απαραίτητους ελέγχους.

Μια λογική προεπιλεγμένη πολιτική

Δεν υπάρχει καθολικό header που να ταιριάζει σε κάθε ιστότοπο, αλλά οι περισσότεροι content και marketing ιστότοποι μπορούν να ξεκινήσουν περιοριστικά.

Μια λογική πρώτη προσέγγιση:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

Στη συνέχεια προσθέστε ξανά μόνο ό,τι πραγματικά χρησιμοποιεί ο ιστότοπος.

Για παράδειγμα:

• Ένα κατάστημα που χρησιμοποιεί Payment Request API μπορεί να χρειάζεται payment=(self).
• Ένας εντοπιστής τοποθεσιών μπορεί να χρειάζεται geolocation=(self) ή μια αξιόπιστη προέλευση χαρτών.
• Μια εφαρμογή τηλεδιασκέψεων μπορεί να χρειάζεται camera=(self) και microphone=(self).
• Ένας ιστότοπος με πολλά βίντεο μπορεί να χρειάζεται fullscreen=(self "https://trusted-video.example").

Το σημαντικό δεν είναι να αντιγράψετε μια τεράστια πολιτική από ένα checklist και να θεωρήσετε ότι τελειώσατε. Ξεκινήστε από την απογραφή των λειτουργιών σας. Ποιες σελίδες χρειάζονται ποιες δυνατότητες του browser; Ποια embeds χρειάζονται ανάθεση; Ποιες δυνατότητες θα ήταν έκπληξη αν ζητούνταν;

Πώς να το αναπτύξετε χωρίς να χαλάσετε πράγματα

Κυκλοφορήστε το όπως οποιοδήποτε άλλο production header: μεθοδικά.

1. Καταγράψτε τη χρήση δυνατοτήτων

Αναζητήστε στο codebase σας κλήσεις σε browser APIs όπως getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB και wake lock APIs.

Έπειτα ελέγξτε τα third-party embeds. Η τεκμηρίωση για παρόχους βίντεο, χαρτών, πληρωμών και ταυτότητας συχνά αναφέρει τις απαιτούμενες τιμές iframe allow.

2. Ξεκινήστε σε περιβάλλον χαμηλού ρίσκου

Προσθέστε ένα περιοριστικό header σε staging και δοκιμάστε βασικές διαδρομές χρηστών. Δώστε προσοχή στα browser console messages. Οι browsers συχνά αναφέρουν πότε μια δυνατότητα μπλοκάρεται από permissions policy.

3. Χρησιμοποιήστε πολιτικές ανά σελίδα όπου χρειάζεται

Μην επιβάλλετε μία καθολική πολιτική αν το προϊόν σας έχει πολύ διαφορετικούς τύπους σελίδων. Ένα blog, ένα checkout, μια σελίδα χάρτη και ένα video room πιθανότατα χρειάζονται διαφορετικές δυνατότητες.

Οι περισσότεροι web servers, frameworks και edge platforms μπορούν να ορίσουν headers υπό όρους ανά path. Αυτό είναι συχνά πιο καθαρό από το να αποδυναμώσετε ολόκληρο τον ιστότοπο για μία λειτουργία.

4. Επαληθεύστε το πραγματικό response

Headers μπορούν να προστεθούν, να αντικατασταθούν, να διπλασιαστούν ή να αφαιρεθούν από CDNs, reverse proxies, app servers και middleware. Ελέγξτε το τελικό response στο browser DevTools ή με command-line tools.

Δοκιμάστε επίσης τα ενσωματωμένα contexts. Το ότι μια top-level σελίδα φαίνεται σωστή δεν εγγυάται ότι ένα iframe έλαβε την ανάθεση που είχατε σκοπό να δώσετε.

5. Τεκμηριώστε τις εξαιρέσεις

Κάθε επιτρεπόμενη δυνατότητα πρέπει να έχει owner και λόγο. Αυτό ακούγεται γραφειοκρατικό μέχρι έξι μήνες αργότερα, όταν κανείς δεν θυμάται γιατί το geolocation άνοιξε σε ένα vendor domain που δεν εμφανίζεται πλέον στη σελίδα.

Συνηθισμένα λάθη σύνταξης

Η σύγχρονη σύνταξη του header είναι συμπαγής αλλά εύκολο να γίνει ελαφρώς λάθος.

Χρησιμοποιήστε κενές παρενθέσεις για να αρνηθείτε μια δυνατότητα:

Permissions-Policy: microphone=()

Χρησιμοποιήστε self για την τρέχουσα προέλευση:

Permissions-Policy: geolocation=(self)

Χρησιμοποιήστε προελεύσεις σε εισαγωγικά για συγκεκριμένες εξωτερικές προελεύσεις:

Permissions-Policy: fullscreen=(self "https://video.example")

Αποφύγετε να βασίζεστε σε παλιά παραδείγματα Feature-Policy, εκτός αν υποστηρίζετε σκόπιμα legacy συμπεριφορά. Το παλαιότερο header χρησιμοποιούσε διαφορετική σύνταξη και δεν είναι αυτό γύρω από το οποίο πρέπει να σχεδιάζετε σήμερα.

Επίσης να θυμάστε ότι η υποστήριξη browser διαφέρει ανά οδηγία. Ένας browser μπορεί να υποστηρίζει το header αλλά όχι μια συγκεκριμένη οδηγία δυνατότητας. Αυτό είναι φυσιολογικό. Αντιμετωπίστε το header ως μέτρο defense-in-depth, όχι ως τον μοναδικό σας έλεγχο ιδιωτικότητας ή ασφάλειας.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Επαληθεύστε ότι η Permissions-Policy σας παραδίδεται όπως προβλέπεται με το Get Headers, το οποίο εμφανίζει τις ακατέργαστες κεφαλίδες απόκρισης που στέλνει ο διακομιστής σας.

<!-- tool-cta:end -->

Η πρακτική αξία για την ιδιωτικότητα

Η αξία του Permissions-Policy για την ιδιωτικότητα δεν είναι ότι κάνει έναν ιστότοπο ανώνυμο ή απαλλαγμένο από trackers. Δεν το κάνει.

Η αξία του είναι ότι περιορίζει την πρόσβαση σε ευαίσθητες δυνατότητες του browser. Τοποθεσία, κάμερα, μικρόφωνο, αισθητήρες συσκευής, local hardware APIs και ροές πληρωμών είναι ισχυρά. Οι περισσότερες σελίδες δεν τα χρειάζονται. Πολλά ενσωματωμένα components δεν θα έπρεπε ποτέ να μπορούν να τα ζητήσουν.

Αυτό είναι πραγματική βελτίωση. Μειώνει τα τυχαία prompts, περιορίζει την περιττή έκθεση δυνατοτήτων και δίνει στην ομάδα σας ένα συγκεκριμένο artifact για έλεγχο όταν κυκλοφορεί νέα λειτουργικότητα.

Η καλύτερη εκδοχή αυτού του header είναι βαρετή: περιοριστική από προεπιλογή, χαλαρωμένη μόνο όπου μια λειτουργία ορατή στον χρήστη το απαιτεί, και δοκιμασμένη ως μέρος της κανονικής διαδικασίας release.