Permissions-Policy در وردپرس چطور امنیت را تقویت میکند؟
Permissions-Policy در وردپرس دسترسی به دوربین، میکروفون و موقعیت را محدود میکند. چرا بدون آن، افزونهها و اسکریپتها آزادانه به منابع کاربر دسترسی دارند؟
Permissions-Policy چیست و چرا برای وردپرس ضروری است؟
Permissions-Policy یک هدر HTTP است که به سایت اجازه میدهد یک سیاست امنیتی برای دسترسی به قابلیتهای مرورگر تعریف کند. این قابلیتها شامل Geolocation (موقعیت جغرافیایی)، Camera (دوربین)، Microphone (میکروفون)، Fullscreen (تمامصفحه)، Payment (پرداخت)، USB، Bluetooth و دهها مورد دیگر است. اگر با Permissions-Policy آشنا شده باشید، میدانید که این هدر جایگزین Feature-Policy شده است.
ضرورت Permissions-Policy برای وردپرس از چند جهت قابل تحلیل است. اول، افزونههای شخص ثالث: بسیاری از افزونهها کدهای خارجی را بارگذاری میکنند که میتوانند به قابلیتهای حساس دسترسی داشته باشند. دوم، اسکریپتهای تبلیغاتی: شبکههای تبلیغاتی اغلب از دسترسی به موقعیت جغرافیایی برای هدفگیری استفاده میکنند. سوم، امنیت کاربر: اگر سایت شما هک شود، مهاجم میتواند از این قابلیتها برای جاسوسی استفاده کند. چهارم، انطباق با حریم خصوصی: قوانینی مثل GDPR دسترسی به دادههای حساس را محدود میکنند. اگر با GDPR و تأثیر آن بر وبسایتهای ایرانی آشنا شده باشید، میدانید که این هدر بخشی از انطباق است.
«Permissions-Policy یک قرارداد است بین سایت و مرورگر: اگر قابلیتی مجاز نباشد، مرورگر آن را مسدود میکند، حتی اگر اسکریپت مخرب درخواست کند.»
اگر با هدرهای امنیتی HTTP و کاربرد آنها آشنا شده باشید، میدانید که Permissions-Policy مکمل سایر هدرهای امنیتی مثل CSP و HSTS است.
| قابلیت | خطر بدون Permissions-Policy | دستور مسدودسازی |
|---|---|---|
| Geolocation | ردیابی موقعیت کاربر | geolocation=() |
| Camera | دسترسی به دوربین | camera=() |
| Microphone | شنود مکالمات | microphone=() |
| Payment | درخواست پرداخت جعلی | payment=() |
| USB | دسترسی به دستگاههای USB | usb=() |
دستورات کلیدی Permissions-Policy
Permissions-Policy دهها دستور مختلف دارد که هرکدام یک قابلیت را کنترل میکند. مهمترین این دستورات عبارتند از:
دستور اول: geolocation. کنترل دسترسی به موقعیت جغرافیایی. مقادیر: * (همه)، self (فقط Same-Origin)، () (هیچکس).
Permissions-Policy: geolocation=()
دستور دوم: camera. کنترل دسترسی به دوربین.
Permissions-Policy: camera=()
دستور سوم: microphone. کنترل دسترسی به میکروفون.
Permissions-Policy: microphone=()
دستور چهارم: fullscreen. کنترل دسترسی به حالت تمامصفحه.
Permissions-Policy: fullscreen=(self)
دستور پنجم: payment. کنترل دسترسی به Payment Request API.
Permissions-Policy: payment=(self)
دستور ششم: usb. کنترل دسترسی به USB.
Permissions-Policy: usb=()
ترکیب چند دستور با کاما:
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(self)
اگر با استانداردهای امنیت وب آشنا شده باشید، میدانید که این دستورات بخشی از یک سیاست امنیتی جامع هستند.
پیادهسازی در وردپرس
پیادهسازی Permissions-Policy در وردپرس در چند گام انجام میشود:
گام اول: افزودن هدر با header() در PHP. سادهترین روش، استفاده از Hook send_headers است:
add_action( 'send_headers', function() {
header( 'Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(self)' );
} );
این کد، هدر را به تمام صفحات اضافه میکند. برای صفحات Admin، معمولاً نیازی به این هدر نیست.
گام دوم: افزودن هدر با Nginx. اگر سایت روی Nginx اجرا میشود:
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(self)" always;
گام سوم: افزودن هدر با Apache. برای Apache، از .htaccess استفاده کنید:
<IfModule mod_headers.c>
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(self)"
</IfModule>
گام چهارم: تست. پس از پیادهسازی، سایت را در مرورگر باز کنید و در DevTools، بخش Network → Headers را بررسی کنید. باید هدر Permissions-Policy را ببینید.
اگر با روشهای افزایش امنیت وبسایت آشنا شده باشید، این گامها برای شما آشناست.
تنظیمات اختصاصی وردپرس
وردپرس چند ویژگی دارد که در تنظیم Permissions-Policy باید در نظر گرفته شوند:
ویژگی اول: ویرایشگر گوتنبرگ. ویرایشگر گوتنبرگ از iframe استفاده میکند و برخی قابلیتها مثل Fullscreen را نیاز دارد. اگر Fullscreen مسدود شود، ویرایشگر ممکن است از کار بیفتد. راهحل: fullscreen=(self).
ویژگی دوم: WooCommerce. اگر از WooCommerce استفاده میکنید، Payment Request API برای پرداختهای سریع نیاز است. راهحل: payment=(self).
ویژگی سوم: فرمهای آپلود. اگر سایت فرم آپلود تصویر یا ویدیو دارد، دسترسی به Camera و Microphone ممکن است لازم باشد. راهحل: camera=(self), microphone=(self).
ویژگی چهارم: نقشههای تعاملی. اگر از Google Maps یا سرویس مشابه استفاده میکنید، Geolocation ممکن است لازم باشد. راهحل: geolocation=(self).
اگر با امنیت وب و اصول آن آشنا شده باشید، میدانید که این تنظیمات باید بر پایه نیازهای واقعی سایت تعریف شوند.
تست و عیبیابی
تست Permissions-Policy در چند سطح انجام میشود:
سطح اول: Chrome DevTools. در Network → Headers، هدر را بررسی کنید. در Console، خطاهای مربوط به Permissions-Policy نمایش داده میشوند.
سطح دوم: Security Headers. ابزارهایی مثل securityheaders.com میتوانند این هدر را بررسی کنند.
سطح سوم: تست عملی. یک اسکریپت ساده بنویسید که درخواست Geolocation کند و ببینید که مسدود میشود:
navigator.geolocation.getCurrentPosition(
() => console.log( 'Allowed' ),
() => console.log( 'Blocked' )
);
اگر با تست امنیت وبسایت آشنا شده باشید، این رویکرد برای شما آشناست.
اشتباهات رایج در پیادهسازی
اشتباه اول: مسدود کردن تمام قابلیتها بدون بررسی نیازها. اگر تمام قابلیتها مسدود شوند، ممکن است بخشهایی از سایت از کار بیفتند. راهحل: تنظیم بر پایه نیاز واقعی.
اشتباه دوم: فراموش کردن payment=(self) برای WooCommerce. اگر Payment مسدود شود، پرداختهای سریع از کار میافتند.
اشتباه سوم: اعمال هدر برای صفحات Admin. اگر Permissions-Policy برای صفحات Admin اعمال شود، ممکن است با ویرایشگر گوتنبرگ تداخل کند.
اشتباه چهارم: عدم تست در مرورگرهای مختلف. Permissions-Policy در مرورگرهای مختلف رفتار متفاوتی دارد.
اشتباه پنجم: اتکا به Permissions-Policy بهتنهایی. این هدر یک لایه امنیتی است، نه جایگزین CSP یا سایر هدرها.
اشتباه ششم: نادیده گرفتن iframeها. اگر سایت از iframe استفاده میکند، باید Permissions-Policy را برای iframeها نیز تنظیم کنید.
اشتباه هفتم: عدم مستندسازی. اگر سیاست خاصی تعریف میشود، باید مستند شود تا در بهروزرسانیهای آینده فراموش نشود.
پرسشهای پرتکرار درباره Permissions-Policy
Permissions-Policy چیست و چرا برای وردپرس ضروری است؟
Permissions-Policy یک هدر HTTP است که کنترل دسترسی به قابلیتهای مرورگر را فراهم میکند. برای وردپرس ضروری است چون افزونههای شخص ثالث و اسکریپتهای تبلیغاتی میتوانند به قابلیتهای حساس دسترسی پیدا کنند و این هدر از این دسترسی جلوگیری میکند.
چگونه Permissions-Policy را در وردپرس پیادهسازی کنم؟
از Hook send_headers و تابع header() استفاده کنید. یا از Nginx با add_header و Apache با Header always set. مثال: Permissions-Policy: geolocation=(), camera=().
دستورات کلیدی Permissions-Policy کدامند؟
Geolocation، Camera، Microphone، Fullscreen، Payment، USB، Bluetooth و دهها مورد دیگر. هر دستور سه مقدار دارد: * (همه)، self (Same-Origin)، () (هیچکس).
آیا Permissions-Policy با ویرایشگر گوتنبرگ سازگار است؟
بله، اما باید fullscreen=(self) تنظیم شود تا ویرایشگر از کار نیفتد. توصیه میشود هدر فقط برای صفحات Front-end اعمال شود.
آیا Permissions-Policy بر سرعت سایت تأثیر میگذارد؟
خیر، تأثیر منفی ندارد. این هدر فقط یک سیاست امنیتی است و در مرورگر اعمال میشود.
چگونه Permissions-Policy را تست کنم؟
از Chrome DevTools برای بررسی هدر، از Security Headers برای تحلیل، و از یک اسکریپت ساده برای تست عملی (مثل درخواست Geolocation) استفاده کنید.
آیا Permissions-Policy جایگزین Feature-Policy است؟
بله، Feature-Policy در سال ۲۰۲۰ منسوخ شد و Permissions-Policy جایگزین آن شد. اگر از Feature-Policy استفاده میکنید، باید به Permissions-Policy مهاجرت کنید.
آیا Permissions-Policy با WooCommerce کار میکند؟
بله، اما باید payment=(self) تنظیم شود تا پرداختهای سریع کار کنند.
آیا Permissions-Policy بر SEO تأثیر میگذارد؟
تأثیر مستقیمی ندارد اما بخشی از امنیت فنی است که میتواند بر اعتماد موتورهای جستجو اثر بگذارد. اگر با سئو تکنیکال و اهمیت آن آشنا شده باشید، میدانید که امنیت یکی از سیگنالهای رتبهبندی است.
آیا Permissions-Policy برای همه سایتها ضروری است؟
برای سایتهایی که از قابلیتهای حساس مرورگر استفاده میکنند یا اسکریپتهای شخص ثالث دارند، ضروری است. برای سایتهای ساده، اولویت پایینتری دارد اما همچنان توصیه میشود.
تحلیل معمارانه سطح ارشد
از منظر معماری نرمافزار، Permissions-Policy یک نمونه از Capability-Based Security است: بهجای اعتماد به اسکریپتها، هر قابلیت بهصورت مستقل مجاز یا مسدود میشود. این رویکرد، در معماریهای مدرن به یک اصل تبدیل شده: از Principle of Least Privilege تا Zero-Trust.
چالش اصلی، Backward Compatibility است: این هدر در مرورگرهای مدرن پشتیبانی میشود اما در مرورگرهای قدیمی نادیده گرفته میشود. راهحل، ترکیب با سایر لایههای امنیتی.
چالش دوم، Ecosystem Compatibility است: اگر سایت از منابع خارجی زیادی استفاده میکند، تنظیم Permissions-Policy میتواند آنها را مسدود کند. راهحل، تنظیم دقیق بر پایه نیازها.
چالش سوم، Observability است: اگر Permissions-Policy قابلیتی را مسدود کند، چگونه میتوان فهمید؟ مرورگر خطا را در Console ثبت میکند اما این خطا به Backend نمیرسد. راهحل، استفاده از Reporting API.
در نهایت، Permissions-Policy یک Evolution است، نه یک Revolution. این هدر، تکامل طبیعی معماری امنیتی وب است: از کنترل متمرکز به کنترل توزیعشده، از اعتماد کامل به اسکریپتها به تأیید هر قابلیت. تیمهایی که این رویکرد را در فرهنگ خود نهادینه میکنند، سیستمهایی میسازند که در برابر طیف گستردهای از حملات مقاوم هستند. اگر با طراحی معماری وب مقیاسپذیر آشنا شده باشید، این رویکرد را بهعنوان یک اصل مهندسی میشناسید.
اگر این تجربه را در یک پروژه واقعی داشتهاید، جالب است بدانید کدام دستور Permissions-Policy بیشترین تأثیر را در افزایش امنیت داشت. تجربه خودتان را در دیدگاهها بنویسید؛ بهخصوص اگر راهحل دیگری پیدا کردهاید که میتواند برای خواننده بعدی مفید باشد. 🔒