Privacy & Security

Ką iš tikrųjų gali apriboti Permissions-Policy antraštė

Praktinis vadovas apie naršyklės funkcijas, kurias galite riboti, ko negalite kontroliuoti ir kaip įdiegti šią antraštę nesugadinant naudingų funkcijų.

The Wux Webtools Team The Wux Webtools Team 8 min skaityti Pagal AI, peržiūrėta žmogaus
A browser interface with feature toggles limiting access for a page and embedded frames.
Turinys
  1. Trumpai
  2. Ką kontroliuoja Permissions-Policy
  3. Ką ji gali apriboti jūsų pačių puslapiuose
  4. Ką ji gali apriboti iframes
  5. Ko ji negali apriboti
  6. Protinga numatytoji politika
  7. Kaip įdiegti nesugadinant funkcijų
  8. 1. Inventorizuokite funkcijų naudojimą
  9. 2. Pradėkite mažos rizikos aplinkoje
  10. 3. Kur reikia, naudokite puslapiui specifines politikas
  11. 4. Patikrinkite tikrąjį atsaką
  12. 5. Dokumentuokite išimtis
  13. Dažnos sintaksės klaidos
  14. Praktinė privatumo vertė

Trumpai

Permissions-Policy yra HTTP atsako antraštė, leidžianti svetainei apriboti prieigą prie tam tikrų naršyklės funkcijų: kameros, mikrofono, geolokacijos, viso ekrano režimo, mokėjimų, jutiklių ir ilgo mažesnių API sąrašo.

Tai nėra bendras privatumo skydas. Ji nesustabdys viso sekimo, neužblokuos cookies, neužkirs kelio tinklo užklausoms ir nepadarys trečiųjų šalių JavaScript saugaus. Tai, ką ji gali atlikti gerai, yra siauriau, bet vis tiek vertinga: sumažinti naršyklės galimybes, prieinamas jūsų pačių puslapiams ir įterptiems rėmeliams.

Tai svarbu, nes šiuolaikinės svetainės sujungiamos iš analitikos fragmentų, medijos įterpinių, pokalbių valdiklių, sutikimų valdymo priemonių, reklamos scriptų, žemėlapių, mokėjimo srautų ir vidinių eksperimentų. Daugumai šių komponentų nereikia prieigos prie galingų įrenginio API. Gera politika tai aiškiai įvardija.

Jei jau peržiūrite antraštes produkcinėje aplinkoje, susiekite šį darbą su tiesioginiu tikrojo atsako patikrinimu. Mūsų vadove apie peradresavimų ir HTTP antraščių derinimą produkcinėje aplinkoje aprašomas čia svarbus įprotis: tikrinkite, ką naršyklė iš tikrųjų gauna, o ne tai, ką pagal konfigūracijos failą turėtų gauti.

Ką kontroliuoja Permissions-Policy

Antraštė kontroliuoja prieigą prie įvardytų naršyklės funkcijų. Tikslus sąrašas laikui bėgant keičiasi, nes keičiasi naršyklės API, tačiau dažnos direktyvos yra:

  • camera
  • microphone
  • geolocation
  • fullscreen
  • payment
  • usb
  • bluetooth
  • accelerometer
  • gyroscope
  • magnetometer
  • screen-wake-lock
  • clipboard-read
  • clipboard-write
  • publickey-credentials-get
  • interest-cohort senesnėse diskusijose, dabar daugiausia istorinė

Direktyva gali leisti funkciją niekam, dabartiniam origin arba pasirinktiems origin. Pavyzdžiui:

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

Tai reiškia, kad kamera ir mikrofonas dokumentui bei jo įdėtiems naršymo kontekstams išjungti, o geolokacija leidžiama tik tam pačiam origin.

Labiau leidžiantis pavyzdys:

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

Tai leidžia jūsų pačių origin ir vienam įvardytam žemėlapių teikėjui naudoti geolokaciją, o jūsų pačių origin ir vaizdo teikėjui prašyti viso ekrano režimo.

Politiką įvertina naršyklė. Jei funkcija neleidžiama, JavaScript, naudojantis tą API, turėtų nepavykti arba elgtis taip, lyg funkcija būtų neprieinama. Tikslus nesėkmės būdas priklauso nuo API. Kartais promise atmetamas. Kartais galimybė tiesiog neatrodo tinkama naudoti.

Ką ji gali apriboti jūsų pačių puslapiuose

Pirmosios šalies puslapiuose Permissions-Policy naudingiausia kaip apsauginis ribotuvas. Ji sumažina atsitiktinio ar netikėto kodo poveikio zoną.

Pavyzdžiui, rinkodaros puslapiui tikriausiai nereikia mikrofono, kameros, Bluetooth, USB, judesio jutiklių ar mokėjimų API. Šias funkcijas galite uždrausti globaliai:

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

Tai nepadaro kiekvieno puslapio scripto patikimo. Tačiau tai reiškia, kad jei tag manager eksperimentas, pažeista priklausomybė ar įklijuotas valdiklis bandys iškviesti ribojamą API, naršyklė neturėtų suteikti prieigos.

Komandoms, kuriose daug prisidedančių žmonių, tai naudinga numatytoji nuostata. Ji perkelia pokalbį nuo migloto pasitikėjimo prie aiškių galimybių. Jei būsimai funkcijai iš tiesų reikės kameros, kažkas turės pakeisti politiką ir paaiškinti kodėl.

Tai tinkamos rūšies trintis.

Ką ji gali apriboti iframes

Antraštė tampa ypač naudinga dirbant su įterptu turiniu.

Naršyklės jau laiko iframes atskirais naršymo kontekstais, tačiau įterptas trečiosios šalies turinys vis tiek gali prašyti galingų funkcijų, jei tai leidžia politika ir iframe atributai. Permissions-Policy leidžia pirminiam puslapiui nustatyti viršutinę ribą.

Pavyzdžiui, jei jūsų puslapis įterpia vaizdo grotuvą, pagalbos valdiklį ir žemėlapį, galite nesuteikti kiekvienam rėmeliui prieigos prie kiekvienos funkcijos. Galite leisti viso ekrano režimą tik vaizdo rėmeliui, o geolokaciją tik žemėlapio rėmeliui.

Reikia suprasti du sluoksnius:

  1. HTTP Permissions-Policy antraštė nustato dokumento politiką.
  2. iframe allow atributas gali perduoti konkrečias funkcijas rėmeliui, bet tik neviršydamas to, ką leidžia pirminė politika.

Paprastas iframe gali atrodyti taip:

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

Jei jūsų antraštė visiškai draudžia viso ekrano režimą, iframe atributas negali panaikinti šio draudimo. Jei jūsų antraštė leidžia viso ekrano režimą tam origin, iframe atributas gali jį perduoti.

Ši hierarchija yra viena iš priežasčių, kodėl verta naudoti antraštę. Ji suteikia platformos ar saugumo komandoms būdą nustatyti visos svetainės ribas, kartu leidžiant produkto komandoms įjungti konkrečius įterpinius ten, kur jų reikia.

Ko ji negali apriboti

Čia komandos kartais pervertina antraštę.

Permissions-Policy nepakeičia turinio saugumo politikos. Ji nenusprendžia, kurie scriptai gali būti įkelti. Ji nesustabdo scripto nuo duomenų siuntimo tinklu. Ji nevalo HTML. Ji neapsaugo nuo XSS. Ji neblokuoja formų spam. Jei problema yra piktnaudžiavimas formomis, pradėkite nuo mechanikos, aprašytos straipsnyje kodėl jūsų kontaktų forma yra didžiausia spam rizika, o ne nuo šios antraštės.

Ji taip pat nepakeičia cookies valdymo. Cookies, local storage, sutikimai, trečiųjų šalių įterpiniai ir naršyklių sekimo apsaugos yra atskiros temos. Jei plačiau peržiūrite privatumo kontrolės priemones, cookies aplinkai verta skirti atskirą peržiūrą; praktiniai pokyčiai aptarti straipsnyje kas pasikeitė dėl cookies 2026 m. ir ką su tuo daryti.

Svarbiausia, Permissions-Policy nepadaro trečiųjų šalių JavaScript privataus. Jei įkeliate trečiosios šalies scriptą į savo pirmosios šalies puslapį, jis paprastai veikia su jūsų puslapio privilegijomis, atsižvelgiant į kitus naršyklės apribojimus ir jūsų saugumo antraštes. Drausti prieigą prie kameros yra gerai. Tai nesustabdo to scripto nuo DOM turinio skaitymo, naudotojo veiksmų stebėjimo ar leidžiamų tinklo užklausų siuntimo.

Tam reikia kitų kontrolės priemonių: kruopščios tiekėjų atrankos, CSP, sandboxed iframes, Subresource Integrity ten, kur taikoma, duomenų minimizavimo ir nuobodžių, bet būtinų peržiūrų.

Protinga numatytoji politika

Nėra universalios antraštės, tinkančios kiekvienai svetainei, tačiau dauguma turinio ir rinkodaros svetainių gali pradėti nuo ribojančio varianto.

Pagrįstas pirmas žingsnis:

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

Tada grąžinkite tik tai, ką svetainė iš tikrųjų naudoja.

Pavyzdžiui:

  • Parduotuvei, naudojančiai Payment Request API, gali reikėti payment=(self).
  • Vietos paieškos funkcijai gali reikėti geolocation=(self) arba patikimo žemėlapių origin.
  • Konferencijų programai gali reikėti camera=(self) ir microphone=(self).
  • Vaizdo turiniui intensyviai naudojamai svetainei gali reikėti fullscreen=(self "https://trusted-video.example").

Svarbiausia ne nukopijuoti milžinišką politiką iš kontrolinio sąrašo ir laikyti darbą baigtu. Pradėkite nuo savo funkcijų inventoriaus. Kuriems puslapiams reikia kokių naršyklės galimybių? Kuriems įterpiniams reikia delegavimo? Kurios funkcijos nustebintų, jei būtų paprašytos?

Kaip įdiegti nesugadinant funkcijų

Diekite tai kaip bet kurią kitą produkcinę antraštę: apgalvotai.

1. Inventorizuokite funkcijų naudojimą

Ieškokite savo kodo bazėje naršyklės API iškvietimų, tokių kaip getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB ir wake lock API.

Tada patikrinkite trečiųjų šalių įterpinius. Vaizdo, žemėlapių, mokėjimų ir tapatybės teikėjų dokumentacijoje dažnai nurodomos būtinos iframe allow reikšmės.

2. Pradėkite mažos rizikos aplinkoje

Pridėkite ribojančią antraštę staging aplinkoje ir ištestuokite pagrindines naudotojų keliones. Atkreipkite dėmesį į naršyklės konsolės pranešimus. Naršyklės dažnai praneša, kai funkciją užblokuoja permissions policy.

3. Kur reikia, naudokite puslapiui specifines politikas

Neverskite vienos globalios politikos, jei jūsų produktas turi labai skirtingų puslapių tipų. Blogui, atsiskaitymui, žemėlapio puslapiui ir vaizdo kambariui tikriausiai reikia skirtingų galimybių.

Dauguma web serverių, frameworkų ir edge platformų gali nustatyti antraštes sąlygiškai pagal path. Tai dažnai švariau nei silpninti visą svetainę dėl vienos funkcijos.

4. Patikrinkite tikrąjį atsaką

Antraštes gali pridėti, perrašyti, dubliuoti arba pašalinti CDN, reverse proxies, app serveriai ir middleware. Patikrinkite galutinį atsaką naršyklės DevTools arba komandinės eilutės įrankiais.

Taip pat testuokite įterptus kontekstus. Tai, kad aukščiausio lygio puslapis atrodo teisingas, negarantuoja, kad iframe gavo jūsų numatytą delegavimą.

5. Dokumentuokite išimtis

Kiekviena leidžiama funkcija turėtų turėti savininką ir priežastį. Tai skamba biurokratiškai iki to momento po šešių mėnesių, kai niekas neprisimena, kodėl geolocation buvo atvertas tiekėjo domenui, kurio puslapyje nebematyti.

Dažnos sintaksės klaidos

Šiuolaikinė antraštės sintaksė yra kompaktiška, bet lengva šiek tiek suklysti.

Naudokite tuščius skliaustus funkcijai uždrausti:

Permissions-Policy: microphone=()

Naudokite self dabartiniam origin:

Permissions-Policy: geolocation=(self)

Naudokite kabutėmis apgaubtus origin konkretiems išoriniams origin:

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

Venkite remtis senais Feature-Policy pavyzdžiais, nebent sąmoningai palaikote legacy elgseną. Senesnė antraštė naudojo kitokią sintaksę ir šiandien neturėtų būti jūsų projektavimo pagrindas.

Taip pat atminkite, kad naršyklių palaikymas skiriasi pagal direktyvą. Naršyklė gali palaikyti antraštę, bet nepalaikyti konkrečios funkcijos direktyvos. Tai normalu. Laikykite šią antraštę defense-in-depth priemone, o ne vienintele privatumo ar saugumo kontrole.

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

💡 Išbandykite: Patikrinkite, ar jūsų Permissions-Policy pateikiama taip, kaip numatyta, naudodami Get Headers, kuris rodo neapdorotas atsako antraštes, kurias siunčia jūsų serveris.

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

Praktinė privatumo vertė

Permissions-Policy privatumo vertė nėra ta, kad ji padaro svetainę anonimišką ar be sekiklių. Ji to nepadaro.

Jos vertė yra ta, kad ji susiaurina prieigą prie jautrių naršyklės galimybių. Vieta, kamera, mikrofonas, įrenginio jutikliai, vietinės aparatinės įrangos API ir mokėjimų srautai yra galingi. Daugumai puslapių jų nereikia. Daugelis įterptų komponentų niekada neturėtų galėti jų prašyti.

Tai tikras pagerinimas. Tai sumažina atsitiktinius raginimus, apriboja nereikalingą galimybių atskleidimą ir suteikia jūsų komandai konkretų artefaktą peržiūrai, kai išleidžiama nauja funkcija.

Geriausia šios antraštės versija yra nuobodi: ribojanti pagal nutylėjimą, atlaisvinama tik ten, kur to reikalauja naudotojui matoma funkcija, ir testuojama kaip įprasto išleidimo proceso dalis.

Dažnai užduodami klausimai

Ar Permissions-Policy yra tas pats kaip Feature-Policy?
Ne. Permissions-Policy yra šiuolaikinis senesnės Feature-Policy antraštės pakaitalas. Kai kuriuose senesniuose straipsniuose ir fragmentuose vis dar naudojama Feature-Policy sintaksė, tačiau naujos implementacijos turėtų naudoti Permissions-Policy.
Ar Permissions-Policy gali sustabdyti trečiųjų šalių sekimą?
Viena pati – ne. Ji gali blokuoti prieigą prie tam tikrų naršyklės funkcijų, bet nesustabdo scriptų įkėlimo, cookies nustatymo ten, kur tai leidžiama, puslapio turinio skaitymo ar tinklo užklausų siuntimo. Naudokite ją kartu su CSP, sutikimų kontrolėmis, duomenų minimizavimu ir atsargiu tiekėjų valdymu.
Ar kiekviena svetainė turėtų uždrausti kamerą ir mikrofoną?
Dauguma svetainių – taip. Jei jūsų svetainė neteikia vaizdo įrašymo, konferencijų, tapatybės patvirtinimo ar kitos funkcijos, kuriai aiškiai reikia medijos fiksavimo, kameros ir mikrofono draudimas yra protinga numatytoji nuostata.
Ar iframe allow atributas gali panaikinti antraštę?
Ne. Pirminio dokumento politika nustato viršutinę ribą. iframe allow atributas gali deleguoti funkciją tik tada, jei pirminė politika leidžia tą funkciją rėmelio origin.
Ar nepalaikomos direktyvos sugadins senas naršykles?
Paprastai nepalaikomos direktyvos ignoruojamos. Vis tiek turėtumėte testuoti svarbias naudotojų keliones palaikomose naršyklėse, nes atskirų API elgsena ir konsolės pranešimai gali skirtis.

Šaltiniai ir tolesnis skaitymas

  1. MDN Web Docs: Permissions-Policy header
  2. W3C: Permissions Policy specification
  3. web.dev: Permissions Policy
  4. Chrome Developers: Controlling browser features with Permissions Policy
Apie autorių
The Wux Webtools Team

Paskutinį kartą atnaujinta:

Tęsti skaitymą