Security Headers در PHP؛ آموزش هدرهای امنیتی HTTP

امنیت یک وب‌سایت فقط به رمز عبور، Session، دیتابیس یا کدنویسی PHP محدود نمی‌شود.

مرورگر نیز در اجرای صفحات وب نقش بسیار مهمی دارد و سرور می‌تواند با ارسال HTTP Headerهای امنیتی، به مرورگر اعلام کند که برخی رفتارها را چگونه مدیریت کند.

برای مثال می‌توانیم به مرورگر بگوییم:

فقط از HTTPS استفاده کند.
فایل‌های JavaScript را فقط از منابع مشخص اجرا کند.
MIME Type فایل‌ها را حدس نزند.
اطلاعات Referrer را محدود کند.
دسترسی بعضی قابلیت‌های مرورگر مانند Camera یا Microphone محدود شود.

به این Headerها معمولاً Security Headers یا HTTP Security Headers گفته می‌شود.

در این مقاله مهم‌ترین Security Headerها را بررسی می‌کنیم و نحوه ارسال آن‌ها در PHP را با مثال عملی یاد می‌گیریم.

# Security Headers چیست؟

Security Headerها Headerهای HTTP هستند که برای کنترل رفتار مرورگر و کاهش برخی ریسک‌های امنیتی ارسال می‌شوند.

یک Response ساده ممکن است چیزی شبیه این باشد:


HTTP/1.1 200 OK

Content-Type: text/html

اما می‌توانیم Headerهای امنیتی بیشتری اضافه کنیم:


Content-Security-Policy: ...

Strict-Transport-Security: ...

X-Content-Type-Options: nosniff

Referrer-Policy: ...

Permissions-Policy: ...

در PHP می‌توان این Headerها را با تابع header() ارسال کرد.

# چرا Security Headers مهم هستند؟

فرض کنید برنامه شما در برابر XSS بررسی‌های لازم را انجام داده است.

با این حال، یک لایه دفاعی دیگر نیز می‌تواند وجود داشته باشد.

مثلاً:


Application Security

        ↓

Browser Security Policy

Security Headerها جایگزین کدنویسی امن نیستند، اما می‌توانند یک لایه دفاعی اضافه ایجاد کنند.

به همین دلیل بهتر است Security Headers را بخشی از طراحی امنیتی پروژه بدانیم، نه یک راهکار مستقل.

# مهم‌ترین Security Headers

در این مقاله Headerهای زیر را بررسی می‌کنیم:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
X-Frame-Options

همچنین به Headerهای قدیمی یا منسوخ نیز اشاره می‌کنیم تا بدانیم کدام روش‌ها دیگر انتخاب مناسبی نیستند.

# تنظیم Security Header در PHP

در ساده‌ترین حالت:


<?php



header('X-Content-Type-Options: nosniff');

header('Referrer-Policy: strict-origin-when-cross-origin');

نکته مهم:

Header باید قبل از ارسال هرگونه خروجی به Browser ارسال شود.

این کد اشتباه است:


echo '<h1>Hello</h1>';



header('X-Content-Type-Options: nosniff');

زیرا ممکن است Header قبلاً ارسال شده باشد.

خطایی مانند:


Headers already sent

ممکن است مشاهده شود.

# 1. Content-Security-Policy یا CSP

یکی از مهم‌ترین Security Headerها:


Content-Security-Policy

است.

CSP به مرورگر اعلام می‌کند منابع صفحه از چه مکان‌هایی اجازه Load یا Execute شدن دارند.

CSP می‌تواند در کاهش ریسک‌هایی مانند XSS کمک کند.

# یک CSP ساده

مثلاً:


header(

    "Content-Security-Policy: default-src 'self'"

);

یعنی به صورت پیش‌فرض منابع فقط از Origin خود سایت مجاز باشند.

# default-src چیست؟

این Directive به عنوان Policy پیش‌فرض برای انواع مختلف Resourceها استفاده می‌شود.

مثلاً:


default-src 'self'

یعنی منابع پیش‌فرض فقط از همان Origin دریافت شوند.

اما یک سایت واقعی معمولاً منابع مختلفی دارد:


JavaScript

CSS

Images

Fonts

API

Videos

Frames

بنابراین CSP واقعی ممکن است پیچیده‌تر باشد.

# مثال CSP دقیق‌تر


header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "img-src 'self' https: data:; "

    . "style-src 'self'; "

    . "script-src 'self'; "

    . "font-src 'self' https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

این Policy یک مثال آموزشی است و باید با منابع واقعی پروژه هماهنگ شود.

# چرا نباید کورکورانه CSP را کپی کنیم؟

فرض کنید سایت شما از:


Google Fonts

Google Analytics

CDN

YouTube

Cloudflare

External API

استفاده می‌کند.

اگر CSP فقط این باشد:


default-src 'self'

ممکن است بخش‌هایی از سایت از کار بیفتند.

بنابراین CSP باید بر اساس Resourceهای واقعی پروژه طراحی شود.

# script-src

این Directive مشخص می‌کند JavaScript از چه منابعی اجازه اجرا دارد.

مثلاً:


script-src 'self'

یعنی Scriptهای خارجی مجاز نیستند.

این موضوع می‌تواند در کاهش سطح حمله XSS مؤثر باشد.

# مشکل Inline Script

فرض کنید HTML شما این باشد:


<script>

    alert('Hello');

</script>

اگر CSP شما:


script-src 'self'

باشد، این Inline Script معمولاً اجازه اجرا نخواهد داشت.

ممکن است وسوسه شویم بنویسیم:


script-src 'self' 'unsafe-inline'

اما unsafe-inline محدودیت CSP روی Inline Script را کاهش می‌دهد.

بنابراین نباید صرفاً برای رفع خطا، آن را بدون بررسی به Policy اضافه کنیم.

# استفاده از Nonce در CSP

یکی از روش‌های مناسب‌تر برای Scriptهای Inline موردنیاز، استفاده از Nonce است.

در PHP:


$nonce = base64_encode(

    random_bytes(16)

);



header(

    "Content-Security-Policy: "

    . "script-src 'self' 'nonce-$nonce'"

);

سپس در HTML:


<script nonce="<?= htmlspecialchars(

    $nonce,

    ENT_QUOTES,

    'UTF-8'

) ?>">

    console.log('Allowed script');

</script>

Nonce باید در هر Response به صورت تصادفی تولید شود.

# چرا Nonce مهم است؟

فرض کنید مهاجم تلاش کند یک Script غیرمجاز تزریق کند.

اگر Script او Nonce صحیح را نداشته باشد، CSP می‌تواند مانع اجرای آن شود.

البته CSP نباید جایگزین جلوگیری از XSS در کد برنامه شود.

# CSP و XSS

در مقاله XSS یاد گرفتیم که باید داده‌های خروجی را به شکل صحیح Escape کنیم.

CSP یک لایه دفاعی اضافه است:


Secure Output

      +

CSP

نه:


CSP

=

XSS Protection

یعنی CSP نباید باعث شود ورودی کاربر را بدون Escape در HTML قرار دهیم.

# object-src 'none'

می‌توانیم Objectهای قدیمی و غیرضروری را غیرفعال کنیم:


object-src 'none'

مثلاً:


header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "object-src 'none';"

);

این Directive می‌تواند سطح حمله را کاهش دهد.

# frame-ancestors

برای کنترل اینکه چه Originهایی اجازه دارند صفحه شما را داخل Frame قرار دهند استفاده می‌شود.

مثلاً:


frame-ancestors 'self'

یعنی فقط صفحات همان Origin اجازه Frame کردن صفحه را داشته باشند.

این Directive برای کنترل Clickjacking نیز مفید است.

# 2. Strict-Transport-Security یا HSTS

Header مهم دیگر:


Strict-Transport-Security

است.

HSTS به مرورگر اعلام می‌کند که برای دامنه مشخص، ارتباط HTTP نباید استفاده شود و باید HTTPS ترجیح داده شود.

مثلاً:


header(

    'Strict-Transport-Security: max-age=31536000'

);

یعنی مرورگر Policy را برای یک سال نگه دارد.

# HSTS چه زمانی باید فعال شود؟

HSTS را باید زمانی فعال کنید که سایت شما واقعاً HTTPS را به درستی پشتیبانی می‌کند.

یعنی:


HTTP

 ↓

HTTPS

و تمام منابع و مسیرهای موردنیاز نیز با HTTPS قابل دسترسی باشند.

فعال کردن HSTS بدون بررسی کامل HTTPS می‌تواند باعث مشکلات دسترسی برای کاربران شود.

# HSTS و includeSubDomains

می‌توان نوشت:


header(

    'Strict-Transport-Security: '

    . 'max-age=31536000; includeSubDomains'

);

includeSubDomains باعث می‌شود Policy برای Subdomainها نیز اعمال شود.

بنابراین قبل از استفاده باید مطمئن شوید تمام Subdomainهای مربوطه نیز HTTPS را پشتیبانی می‌کنند.

# preload چیست؟

ممکن است Headerهایی مانند این را ببینید:


Strict-Transport-Security:

max-age=31536000;

includeSubDomains;

preload

preload موضوعی جداگانه و وابسته به شرایط دامنه و الزامات سرویس HSTS Preload است.

نباید صرفاً به دلیل دیدن آن در نمونه‌های اینترنتی، بدون بررسی شرایط دامنه آن را اضافه کنیم.

# 3. X-Content-Type-Options

Header بسیار ساده اما کاربردی:


X-Content-Type-Options: nosniff

در PHP:


header(

    'X-Content-Type-Options: nosniff'

);

این Header به مرورگر اعلام می‌کند که MIME Type اعلام‌شده را بدون حدس زدن نوع محتوا دنبال کند.

# چرا nosniff مهم است؟

فرض کنید سرور اعلام کند:


Content-Type: text/plain

اما Browser تلاش کند نوع دیگری را حدس بزند.

nosniff می‌تواند از برخی رفتارهای MIME Sniffing جلوگیری کند.

به همین دلیل معمولاً Header مفیدی برای سایت‌هاست.

# 4. Referrer-Policy

زمانی که کاربر از صفحه‌ای به صفحه دیگر می‌رود، ممکن است اطلاعاتی درباره صفحه قبلی به مقصد ارسال شود.

Header:


Referrer-Policy

نحوه ارسال این اطلاعات را کنترل می‌کند.

یک مقدار متداول:


strict-origin-when-cross-origin

در PHP:


header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);

# Referrer چیست؟

فرض کنیم کاربر از:


https://example.com/products/product-1

به یک سایت دیگر می‌رود.

اطلاعات مربوط به صفحه مبدأ می‌تواند در برخی شرایط در قالب Referrer ارسال شود.

Referrer Policy مشخص می‌کند چه مقدار از این اطلاعات ارسال شود.

# چرا Referrer Policy مهم است؟

ممکن است URL شامل اطلاعاتی باشد که نباید به سایت دیگر منتقل شوند.

مثلاً:


https://example.com/account/reset-password/...

به همین دلیل کنترل Referrer می‌تواند یک لایه حریم خصوصی و امنیتی ایجاد کند.

# 5. Permissions-Policy

مرورگر قابلیت‌های مختلفی دارد، مانند:

Camera
Microphone
Geolocation
Payment
USB
Screen Wake Lock

اگر سایت به برخی از این قابلیت‌ها نیاز ندارد، می‌توان دسترسی آن‌ها را محدود کرد.

مثلاً:


header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);

یعنی این قابلیت‌ها برای صفحات سایت غیرفعال شوند.

# چرا Permissions-Policy مهم است؟

اصل مهم امنیتی این است:

> هر قابلیتی که برنامه نیاز ندارد، بهتر است بی‌دلیل در دسترس نباشد.

مثلاً اگر سایت شما اصلاً از Microphone استفاده نمی‌کند:


microphone=()

می‌تواند آن را محدود کند.

# 6. X-Frame-Options

Header دیگری که برای کنترل نمایش صفحه داخل Frame استفاده می‌شود:


X-Frame-Options

مثلاً:


header(

    'X-Frame-Options: SAMEORIGIN'

);

یعنی صفحه فقط توسط همان Origin در Frame نمایش داده شود.

مقدار دیگری که ممکن است ببینید:


DENY

که نمایش صفحه در Frame را به طور کامل محدود می‌کند.

# X-Frame-Options یا CSP frame-ancestors؟

در پروژه‌های جدید، frame-ancestors در CSP کنترل دقیق‌تری ارائه می‌دهد.

مثلاً:


Content-Security-Policy:

frame-ancestors 'self'

می‌تواند سیاست مربوط به Frame را مشخص کند.

X-Frame-Options همچنان ممکن است برای سازگاری با برخی Clientها مفید باشد.

# Headerهای قدیمی

ممکن است در بعضی آموزش‌های قدیمی Header زیر را ببینید:


X-XSS-Protection

مثلاً:


header('X-XSS-Protection: 1; mode=block');

اما این Header راهکار مدرن و قابل اتکایی برای محافظت در برابر XSS محسوب نمی‌شود و در مرورگرهای مدرن اهمیت سابق را ندارد.

به جای تکیه بر آن، باید روی مواردی مانند:


Output Encoding

+

Input Validation

+

CSP

تمرکز کرد.

# مجموعه Headerهای پایه

برای یک سایت ساده HTTPS می‌توان چیزی شبیه این داشت:


<?php



header(

    'X-Content-Type-Options: nosniff'

);



header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);



header(

    'X-Frame-Options: SAMEORIGIN'

);



header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);

اگر HTTPS به صورت کامل و صحیح برقرار است:


header(

    'Strict-Transport-Security: max-age=31536000'

);

و برای CSP باید Policy متناسب با منابع واقعی سایت تعریف شود.

# ساخت Helper برای Security Headers

بهتر است Headerها را در همه فایل‌ها تکرار نکنیم.

می‌توانیم یک فایل ایجاد کنیم:


config/security.php

یا:


src/Security/SecurityHeaders.php

مثلاً:


<?php



function applySecurityHeaders(): void

{

    header(

        'X-Content-Type-Options: nosniff'

    );



    header(

        'Referrer-Policy: strict-origin-when-cross-origin'

    );



    header(

        'X-Frame-Options: SAMEORIGIN'

    );



    header(

        'Permissions-Policy: '

        . 'camera=(), '

        . 'microphone=(), '

        . 'geolocation=()'

    );

}

سپس:


applySecurityHeaders();

# استفاده از CSP با Nonce در PHP

برای پروژه‌ای که Inline Script کنترل‌شده دارد:


<?php



$nonce = base64_encode(

    random_bytes(16)

);



header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "script-src 'self' 'nonce-$nonce'; "

    . "style-src 'self'; "

    . "img-src 'self' data: https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

سپس:


<script nonce="<?= htmlspecialchars(

    $nonce,

    ENT_QUOTES,

    'UTF-8'

) ?>">

    console.log('Allowed');

</script>

# آیا unsafe-inline استفاده کنیم؟

در CSP ممکن است برای رفع خطا به این شکل عمل کنیم:


script-src 'self' 'unsafe-inline'

اما این کار محدودیت CSP روی Inline Script را کاهش می‌دهد.

بنابراین بهتر است ابتدا معماری JavaScript را اصلاح کنیم و تا حد امکان:


External Script

+

Nonce

+

Hash

را بررسی کنیم.

# CSP برای سایت‌های واقعی

فرض کنید سایت از این منابع استفاده می‌کند:


cmsnevis.ir

Google Fonts

YouTube

Analytics

CDN

API

در این حالت نمی‌توانیم یک CSP عمومی را بدون بررسی روی سایت قرار دهیم.

باید ابتدا بفهمیم چه Resourceهایی واقعاً استفاده می‌شوند.

بعد Policy را مرحله به مرحله محدود کنیم.

# CSP Report-Only

یکی از روش‌های مناسب برای تست CSP این است که ابتدا به جای اعمال مستقیم Policy از:


Content-Security-Policy-Report-Only

استفاده کنیم.

مثلاً:


header(

    "Content-Security-Policy-Report-Only: "

    . "default-src 'self'; "

    . "img-src 'self' https: data:; "

    . "script-src 'self';"

);

در این حالت Policy برای گزارش تخلف‌ها استفاده می‌شود، بدون اینکه الزاماً Resource را مسدود کند.

این روش برای پیدا کردن منابعی که ممکن است با CSP واقعی تداخل داشته باشند مفید است.

# Security Headers در آپلود فایل

Security Headers فقط برای صفحه Login نیستند.

مثلاً در سیستم Upload می‌توان از:


X-Content-Type-Options: nosniff

استفاده کرد.

اما این Header جایگزین کنترل‌های Upload نیست.

همچنان باید:

MIME واقعی بررسی شود.
Extension بررسی شود.
نام فایل کنترل شود.
فایل خارج از Web Root ذخیره شود.
اجرای PHP در Upload Directory ممنوع شود.

# Security Headers و XSS

در مقاله XSS دیدیم که باید خروجی را Escape کنیم:


echo htmlspecialchars(

    $name,

    ENT_QUOTES,

    'UTF-8'

);

CSP می‌تواند یک لایه اضافه باشد:


XSS Prevention

       +

CSP

اما نباید بنویسیم:


CSP فعال است

پس Escape لازم نیست.

این کار اشتباه است.

# Security Headers و CSRF

Security Headerها جایگزین CSRF Token نیستند.

برای یک فرم حساس همچنان باید از CSRF Protection استفاده شود.

مثلاً:


CSRF Token

+

SameSite Cookie

+

HTTPS

+

Security Headers

هرکدام نقش متفاوتی دارند.

# Security Headers و Session Cookie

برای Session Cookie نیز می‌توان Attributeهای امنیتی تنظیم کرد.

مثلاً:


session_set_cookie_params([

    'secure' => true,

    'httponly' => true,

    'samesite' => 'Lax',

]);

و سپس:


session_start();

Secure باعث می‌شود Cookie از طریق HTTPS ارسال شود.

HttpOnly دسترسی JavaScript به Cookie را محدود می‌کند.

SameSite نیز در کنترل ارسال Cookie در Contextهای Cross-Site نقش دارد.

# یک نمونه کامل‌تر

می‌توانیم قبل از خروجی صفحه:


<?php



session_set_cookie_params([

    'secure' => true,

    'httponly' => true,

    'samesite' => 'Lax',

]);



session_start();



header(

    'X-Content-Type-Options: nosniff'

);



header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);



header(

    'X-Frame-Options: SAMEORIGIN'

);



header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);



header(

    'Strict-Transport-Security: max-age=31536000'

);



header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "img-src 'self' data: https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

این فقط یک نمونه پایه است.

CSP باید با منابع واقعی پروژه هماهنگ شود و HSTS نیز فقط زمانی مناسب است که HTTPS به شکل صحیح روی دامنه و در صورت نیاز Subdomainها برقرار باشد.

# Security Headers را در کجا قرار دهیم؟

سه محل رایج وجود دارد.

۱. PHP

مثلاً:


header(

    'X-Content-Type-Options: nosniff'

);

برای پروژه‌های PHP ساده مناسب است.

۲. Web Server

اگر Apache یا Nginx دارید، می‌توان Headerها را در Web Server تنظیم کرد.

مزیت:

Headerها می‌توانند برای بخش بزرگ‌تری از سایت به صورت متمرکز اعمال شوند.

۳. Framework Middleware

در Frameworkهایی مانند Laravel می‌توان Security Headerها را در Middleware قرار داد.

این روش برای پروژه‌های بزرگ‌تر مدیریت‌پذیرتر است.

# Security Headers در Apache

برای Apache می‌توان از mod_headers استفاده کرد.

مثلاً:


<IfModule mod_headers.c>



    Header always set X-Content-Type-Options "nosniff"



    Header always set Referrer-Policy \

        "strict-origin-when-cross-origin"



    Header always set X-Frame-Options "SAMEORIGIN"



</IfModule>

برای CSP و HSTS باید Policy متناسب با سایت تنظیم شود.

# Security Headers در Nginx

نمونه:


add_header X-Content-Type-Options "nosniff" always;



add_header Referrer-Policy

    "strict-origin-when-cross-origin" always;



add_header X-Frame-Options "SAMEORIGIN" always;

و برای HSTS، فقط در صورتی که HTTPS به شکل صحیح و دائمی فعال است:


add_header Strict-Transport-Security

    "max-age=31536000" always;

# Security Headers در Laravel

در Laravel بهتر است Headerها را در Middleware متمرکز کنیم.

برای مثال:


<?php



namespace App\Http\Middleware;



use Closure;

use Illuminate\Http\Request;



class SecurityHeaders

{

    public function handle(

        Request $request,

        Closure $next

    ) {

        $response = $next($request);



        $response->headers->set(

            'X-Content-Type-Options',

            'nosniff'

        );



        $response->headers->set(

            'Referrer-Policy',

            'strict-origin-when-cross-origin'

        );



        $response->headers->set(

            'X-Frame-Options',

            'SAMEORIGIN'

        );



        return $response;

    }

}

در Laravel بهتر است Policyها را بر اساس ساختار واقعی پروژه و Middlewareهای موجود تنظیم کنیم و Headerهای امنیتی را در یک نقطه قابل مدیریت قرار دهیم.

# چگونه Security Headers سایت را بررسی کنیم؟

می‌توانیم Response Headerهای سایت را بررسی کنیم.

با curl:


curl -I https://example.com

مثلاً خروجی ممکن است شامل موارد زیر باشد:


HTTP/2 200



content-type: text/html

x-content-type-options: nosniff

referrer-policy: strict-origin-when-cross-origin

x-frame-options: SAMEORIGIN

این روش برای بررسی سریع مناسب است.

# یک اشتباه رایج: کپی کردن CSP از سایت دیگر

CSP یکی از Headerهایی است که نباید صرفاً Copy/Paste شود.

چون CSP به مواردی مانند:


JavaScript

CSS

Images

Fonts

Frames

Analytics

CDN

API

وابسته است.

Policy مناسب یک سایت ممکن است برای سایت دیگری باعث خراب شدن JavaScript یا تصاویر شود.

# یک اشتباه دیگر: فعال کردن HSTS بدون بررسی HTTPS

این Header:


Strict-Transport-Security

را نباید بدون بررسی زیرساخت فعال کرد.

قبل از آن مطمئن شوید:


HTTPS

✓

Certificate

✓

Redirect

✓

Resources

✓

Subdomains در صورت includeSubDomains

✓

همگی درست هستند.

# آیا Security Headers سرعت سایت را کم می‌کنند؟

خود Headerها معمولاً حجم بسیار کمی دارند.

اما بعضی Policyها مانند CSP می‌توانند باعث شوند Browser منابعی را که در Policy مجاز نیستند Load نکند.

بنابراین باید Policy را دقیق تنظیم و تست کرد.

# چک‌لیست Security Headers

قبل از انتشار پروژه این موارد را بررسی کنید:

[ ] HTTPS فعال است.
[ ] HSTS پس از بررسی کامل HTTPS فعال شده است.
[ ] X-Content-Type-Options: nosniff تنظیم شده است.
[ ] Referrer-Policy مشخص شده است.
[ ] Permissions-Policy بر اساس نیاز پروژه تنظیم شده است.
[ ] Clickjacking با CSP frame-ancestors و/یا X-Frame-Options کنترل شده است.
[ ] CSP متناسب با Resourceهای واقعی سایت تنظیم شده است.
[ ] برای Inline Scriptهای ضروری از Nonce یا روش مناسب دیگری استفاده شده است.
[ ] CSP به عنوان جایگزین XSS Protection استفاده نشده است.
[ ] unsafe-inline بدون بررسی اضافه نشده است.
[ ] Headerها قبل از خروجی ارسال می‌شوند.
[ ] Headerها در یک محل متمرکز مدیریت می‌شوند.
[ ] Policyها روی محیط Staging تست شده‌اند.
[ ] CSP در صورت نیاز ابتدا با Report-Only آزمایش شده است.
[ ] Headerهای قدیمی و غیرضروری بدون دلیل استفاده نشده‌اند.

# پرسش‌های متداول

Security Headers در PHP چیست؟

Security Headers، Headerهای HTTP هستند که به مرورگر می‌گویند صفحه و منابع آن را با چه سیاست‌های امنیتی مدیریت کند.

مهم‌ترین Security Header برای PHP چیست؟

هیچ Header واحدی برای همه پروژه‌ها بهترین نیست. CSP، HSTS، X-Content-Type-Options، Referrer-Policy، Permissions-Policy و کنترل Frame هرکدام هدف متفاوتی دارند.

آیا CSP جلوی XSS را می‌گیرد؟

CSP می‌تواند یک لایه دفاعی در برابر برخی سناریوهای XSS باشد، اما جایگزین Escape کردن خروجی، Validation و کدنویسی امن نیست.

آیا HSTS را روی هر سایتی فعال کنیم؟

اگر سایت کاملاً HTTPS است، HSTS می‌تواند مناسب باشد؛ اما قبل از فعال‌سازی باید وضعیت HTTPS و در صورت استفاده includeSubDomains، وضعیت Subdomainها بررسی شود.

آیا `X-Frame-Options` هنوز کاربرد دارد؟

بله، اما برای کنترل دقیق‌تر Frame Ancestors، CSP با frame-ancestors روش مدرن‌تری است.

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

خیر. می‌توان آن‌ها را در PHP، Web Server، Reverse Proxy یا Middleware Framework تنظیم کرد.

# جمع‌بندی

Security Headers یکی از لایه‌های مهم امنیت برنامه‌های وب هستند.

با Headerهایی مانند:


Content-Security-Policy

Strict-Transport-Security

X-Content-Type-Options

Referrer-Policy

Permissions-Policy

X-Frame-Options

می‌توان رفتار Browser را تا حد زیادی کنترل کرد و یک لایه دفاعی اضافه در برابر برخی حملات و سوءاستفاده‌ها ایجاد کرد.

با این حال نباید Security Headers را جایگزین اصول اصلی امنیت برنامه بدانیم.

یک پروژه PHP امن همچنان به مواردی مانند:


Prepared Statements

Output Encoding

CSRF Protection

Secure Sessions

Password Hashing

Rate Limiting

2FA

Secure File Upload

نیاز دارد.

به‌خصوص در مورد CSP باید از Copy/Paste کردن Policyهای آماده خودداری کنیم و آن را متناسب با منابع واقعی پروژه طراحی و تست کنیم.

مقاله پیشنهادی بعدی

در ادامه این کلاستر، مقاله مناسب بعدی می‌تواند CORS در PHP چیست؟ آموزش Cross-Origin Resource Sharing و تنظیم امن API باشد؛ چون بعد از بررسی Headerهای امنیتی، ورود به موضوع درخواست‌های Cross-Origin و امنیت API ارتباط مستقیمی با مباحث REST API و امنیت PHP دارد.

امنیت یک وب‌سایت فقط به رمز عبور، Session، دیتابیس یا کدنویسی PHP محدود نمی‌شود.

برای مثال می‌توانیم به مرورگر بگوییم:

فقط از HTTPS استفاده کند.
فایل‌های JavaScript را فقط از منابع مشخص اجرا کند.
MIME Type فایل‌ها را حدس نزند.
اطلاعات Referrer را محدود کند.
دسترسی بعضی قابلیت‌های مرورگر مانند Camera یا Microphone محدود شود.

به این Headerها معمولاً Security Headers یا HTTP Security Headers گفته می‌شود.

در این مقاله مهم‌ترین Security Headerها را بررسی می‌کنیم و نحوه ارسال آن‌ها در PHP را با مثال عملی یاد می‌گیریم.

# Security Headers چیست؟

Security Headerها Headerهای HTTP هستند که برای کنترل رفتار مرورگر و کاهش برخی ریسک‌های امنیتی ارسال می‌شوند.

یک Response ساده ممکن است چیزی شبیه این باشد:


HTTP/1.1 200 OK

Content-Type: text/html

اما می‌توانیم Headerهای امنیتی بیشتری اضافه کنیم:


Content-Security-Policy: ...

Strict-Transport-Security: ...

X-Content-Type-Options: nosniff

Referrer-Policy: ...

Permissions-Policy: ...

در PHP می‌توان این Headerها را با تابع header() ارسال کرد.

# چرا Security Headers مهم هستند؟

فرض کنید برنامه شما در برابر XSS بررسی‌های لازم را انجام داده است.

با این حال، یک لایه دفاعی دیگر نیز می‌تواند وجود داشته باشد.

مثلاً:


Application Security

        ↓

Browser Security Policy

Security Headerها جایگزین کدنویسی امن نیستند، اما می‌توانند یک لایه دفاعی اضافه ایجاد کنند.

به همین دلیل بهتر است Security Headers را بخشی از طراحی امنیتی پروژه بدانیم، نه یک راهکار مستقل.

# مهم‌ترین Security Headers

در این مقاله Headerهای زیر را بررسی می‌کنیم:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
X-Frame-Options

همچنین به Headerهای قدیمی یا منسوخ نیز اشاره می‌کنیم تا بدانیم کدام روش‌ها دیگر انتخاب مناسبی نیستند.

# تنظیم Security Header در PHP

در ساده‌ترین حالت:


<?php



header('X-Content-Type-Options: nosniff');

header('Referrer-Policy: strict-origin-when-cross-origin');

نکته مهم:

Header باید قبل از ارسال هرگونه خروجی به Browser ارسال شود.

این کد اشتباه است:


echo '<h1>Hello</h1>';



header('X-Content-Type-Options: nosniff');

زیرا ممکن است Header قبلاً ارسال شده باشد.

خطایی مانند:


Headers already sent

ممکن است مشاهده شود.

# 1. Content-Security-Policy یا CSP

یکی از مهم‌ترین Security Headerها:


Content-Security-Policy

است.

CSP به مرورگر اعلام می‌کند منابع صفحه از چه مکان‌هایی اجازه Load یا Execute شدن دارند.

CSP می‌تواند در کاهش ریسک‌هایی مانند XSS کمک کند.

# یک CSP ساده

مثلاً:


header(

    "Content-Security-Policy: default-src 'self'"

);

یعنی به صورت پیش‌فرض منابع فقط از Origin خود سایت مجاز باشند.

# default-src چیست؟

این Directive به عنوان Policy پیش‌فرض برای انواع مختلف Resourceها استفاده می‌شود.

مثلاً:


default-src 'self'

یعنی منابع پیش‌فرض فقط از همان Origin دریافت شوند.

اما یک سایت واقعی معمولاً منابع مختلفی دارد:


JavaScript

CSS

Images

Fonts

API

Videos

Frames

بنابراین CSP واقعی ممکن است پیچیده‌تر باشد.

# مثال CSP دقیق‌تر


header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "img-src 'self' https: data:; "

    . "style-src 'self'; "

    . "script-src 'self'; "

    . "font-src 'self' https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

این Policy یک مثال آموزشی است و باید با منابع واقعی پروژه هماهنگ شود.

# چرا نباید کورکورانه CSP را کپی کنیم؟

فرض کنید سایت شما از:


Google Fonts

Google Analytics

CDN

YouTube

Cloudflare

External API

استفاده می‌کند.

اگر CSP فقط این باشد:


default-src 'self'

ممکن است بخش‌هایی از سایت از کار بیفتند.

بنابراین CSP باید بر اساس Resourceهای واقعی پروژه طراحی شود.

# script-src

این Directive مشخص می‌کند JavaScript از چه منابعی اجازه اجرا دارد.

مثلاً:


script-src 'self'

یعنی Scriptهای خارجی مجاز نیستند.

این موضوع می‌تواند در کاهش سطح حمله XSS مؤثر باشد.

# مشکل Inline Script

فرض کنید HTML شما این باشد:


<script>

    alert('Hello');

</script>

اگر CSP شما:


script-src 'self'

باشد، این Inline Script معمولاً اجازه اجرا نخواهد داشت.

ممکن است وسوسه شویم بنویسیم:


script-src 'self' 'unsafe-inline'

اما unsafe-inline محدودیت CSP روی Inline Script را کاهش می‌دهد.

بنابراین نباید صرفاً برای رفع خطا، آن را بدون بررسی به Policy اضافه کنیم.

# استفاده از Nonce در CSP

یکی از روش‌های مناسب‌تر برای Scriptهای Inline موردنیاز، استفاده از Nonce است.

در PHP:


$nonce = base64_encode(

    random_bytes(16)

);



header(

    "Content-Security-Policy: "

    . "script-src 'self' 'nonce-$nonce'"

);

سپس در HTML:


<script nonce="<?= htmlspecialchars(

    $nonce,

    ENT_QUOTES,

    'UTF-8'

) ?>">

    console.log('Allowed script');

</script>

Nonce باید در هر Response به صورت تصادفی تولید شود.

# چرا Nonce مهم است؟

فرض کنید مهاجم تلاش کند یک Script غیرمجاز تزریق کند.

اگر Script او Nonce صحیح را نداشته باشد، CSP می‌تواند مانع اجرای آن شود.

البته CSP نباید جایگزین جلوگیری از XSS در کد برنامه شود.

# CSP و XSS

در مقاله XSS یاد گرفتیم که باید داده‌های خروجی را به شکل صحیح Escape کنیم.

CSP یک لایه دفاعی اضافه است:


Secure Output

      +

CSP

نه:


CSP

=

XSS Protection

یعنی CSP نباید باعث شود ورودی کاربر را بدون Escape در HTML قرار دهیم.

# object-src 'none'

می‌توانیم Objectهای قدیمی و غیرضروری را غیرفعال کنیم:


object-src 'none'

مثلاً:


header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "object-src 'none';"

);

این Directive می‌تواند سطح حمله را کاهش دهد.

# frame-ancestors

برای کنترل اینکه چه Originهایی اجازه دارند صفحه شما را داخل Frame قرار دهند استفاده می‌شود.

مثلاً:


frame-ancestors 'self'

یعنی فقط صفحات همان Origin اجازه Frame کردن صفحه را داشته باشند.

این Directive برای کنترل Clickjacking نیز مفید است.

# 2. Strict-Transport-Security یا HSTS

Header مهم دیگر:


Strict-Transport-Security

است.

HSTS به مرورگر اعلام می‌کند که برای دامنه مشخص، ارتباط HTTP نباید استفاده شود و باید HTTPS ترجیح داده شود.

مثلاً:


header(

    'Strict-Transport-Security: max-age=31536000'

);

یعنی مرورگر Policy را برای یک سال نگه دارد.

# HSTS چه زمانی باید فعال شود؟

HSTS را باید زمانی فعال کنید که سایت شما واقعاً HTTPS را به درستی پشتیبانی می‌کند.

یعنی:


HTTP

 ↓

HTTPS

و تمام منابع و مسیرهای موردنیاز نیز با HTTPS قابل دسترسی باشند.

فعال کردن HSTS بدون بررسی کامل HTTPS می‌تواند باعث مشکلات دسترسی برای کاربران شود.

# HSTS و includeSubDomains

می‌توان نوشت:


header(

    'Strict-Transport-Security: '

    . 'max-age=31536000; includeSubDomains'

);

includeSubDomains باعث می‌شود Policy برای Subdomainها نیز اعمال شود.

بنابراین قبل از استفاده باید مطمئن شوید تمام Subdomainهای مربوطه نیز HTTPS را پشتیبانی می‌کنند.

# preload چیست؟

ممکن است Headerهایی مانند این را ببینید:


Strict-Transport-Security:

max-age=31536000;

includeSubDomains;

preload

preload موضوعی جداگانه و وابسته به شرایط دامنه و الزامات سرویس HSTS Preload است.

نباید صرفاً به دلیل دیدن آن در نمونه‌های اینترنتی، بدون بررسی شرایط دامنه آن را اضافه کنیم.

# 3. X-Content-Type-Options

Header بسیار ساده اما کاربردی:


X-Content-Type-Options: nosniff

در PHP:


header(

    'X-Content-Type-Options: nosniff'

);

این Header به مرورگر اعلام می‌کند که MIME Type اعلام‌شده را بدون حدس زدن نوع محتوا دنبال کند.

# چرا nosniff مهم است؟

فرض کنید سرور اعلام کند:


Content-Type: text/plain

اما Browser تلاش کند نوع دیگری را حدس بزند.

nosniff می‌تواند از برخی رفتارهای MIME Sniffing جلوگیری کند.

به همین دلیل معمولاً Header مفیدی برای سایت‌هاست.

# 4. Referrer-Policy

زمانی که کاربر از صفحه‌ای به صفحه دیگر می‌رود، ممکن است اطلاعاتی درباره صفحه قبلی به مقصد ارسال شود.

Header:


Referrer-Policy

نحوه ارسال این اطلاعات را کنترل می‌کند.

یک مقدار متداول:


strict-origin-when-cross-origin

در PHP:


header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);

# Referrer چیست؟

فرض کنیم کاربر از:


https://example.com/products/product-1

به یک سایت دیگر می‌رود.

اطلاعات مربوط به صفحه مبدأ می‌تواند در برخی شرایط در قالب Referrer ارسال شود.

Referrer Policy مشخص می‌کند چه مقدار از این اطلاعات ارسال شود.

# چرا Referrer Policy مهم است؟

ممکن است URL شامل اطلاعاتی باشد که نباید به سایت دیگر منتقل شوند.

مثلاً:


https://example.com/account/reset-password/...

به همین دلیل کنترل Referrer می‌تواند یک لایه حریم خصوصی و امنیتی ایجاد کند.

# 5. Permissions-Policy

مرورگر قابلیت‌های مختلفی دارد، مانند:

Camera
Microphone
Geolocation
Payment
USB
Screen Wake Lock

اگر سایت به برخی از این قابلیت‌ها نیاز ندارد، می‌توان دسترسی آن‌ها را محدود کرد.

مثلاً:


header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);

یعنی این قابلیت‌ها برای صفحات سایت غیرفعال شوند.

# چرا Permissions-Policy مهم است؟

اصل مهم امنیتی این است:

> هر قابلیتی که برنامه نیاز ندارد، بهتر است بی‌دلیل در دسترس نباشد.

مثلاً اگر سایت شما اصلاً از Microphone استفاده نمی‌کند:


microphone=()

می‌تواند آن را محدود کند.

# 6. X-Frame-Options

Header دیگری که برای کنترل نمایش صفحه داخل Frame استفاده می‌شود:


X-Frame-Options

مثلاً:


header(

    'X-Frame-Options: SAMEORIGIN'

);

یعنی صفحه فقط توسط همان Origin در Frame نمایش داده شود.

مقدار دیگری که ممکن است ببینید:


DENY

که نمایش صفحه در Frame را به طور کامل محدود می‌کند.

# X-Frame-Options یا CSP frame-ancestors؟

در پروژه‌های جدید، frame-ancestors در CSP کنترل دقیق‌تری ارائه می‌دهد.

مثلاً:


Content-Security-Policy:

frame-ancestors 'self'

می‌تواند سیاست مربوط به Frame را مشخص کند.

X-Frame-Options همچنان ممکن است برای سازگاری با برخی Clientها مفید باشد.

# Headerهای قدیمی

ممکن است در بعضی آموزش‌های قدیمی Header زیر را ببینید:


X-XSS-Protection

مثلاً:


header('X-XSS-Protection: 1; mode=block');

به جای تکیه بر آن، باید روی مواردی مانند:


Output Encoding

+

Input Validation

+

CSP

تمرکز کرد.

# مجموعه Headerهای پایه

برای یک سایت ساده HTTPS می‌توان چیزی شبیه این داشت:


<?php



header(

    'X-Content-Type-Options: nosniff'

);



header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);



header(

    'X-Frame-Options: SAMEORIGIN'

);



header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);

اگر HTTPS به صورت کامل و صحیح برقرار است:


header(

    'Strict-Transport-Security: max-age=31536000'

);

و برای CSP باید Policy متناسب با منابع واقعی سایت تعریف شود.

# ساخت Helper برای Security Headers

بهتر است Headerها را در همه فایل‌ها تکرار نکنیم.

می‌توانیم یک فایل ایجاد کنیم:


config/security.php

یا:


src/Security/SecurityHeaders.php

مثلاً:


<?php



function applySecurityHeaders(): void

{

    header(

        'X-Content-Type-Options: nosniff'

    );



    header(

        'Referrer-Policy: strict-origin-when-cross-origin'

    );



    header(

        'X-Frame-Options: SAMEORIGIN'

    );



    header(

        'Permissions-Policy: '

        . 'camera=(), '

        . 'microphone=(), '

        . 'geolocation=()'

    );

}

سپس:


applySecurityHeaders();

# استفاده از CSP با Nonce در PHP

برای پروژه‌ای که Inline Script کنترل‌شده دارد:


<?php



$nonce = base64_encode(

    random_bytes(16)

);



header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "script-src 'self' 'nonce-$nonce'; "

    . "style-src 'self'; "

    . "img-src 'self' data: https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

سپس:


<script nonce="<?= htmlspecialchars(

    $nonce,

    ENT_QUOTES,

    'UTF-8'

) ?>">

    console.log('Allowed');

</script>

# آیا unsafe-inline استفاده کنیم؟

در CSP ممکن است برای رفع خطا به این شکل عمل کنیم:


script-src 'self' 'unsafe-inline'

اما این کار محدودیت CSP روی Inline Script را کاهش می‌دهد.

بنابراین بهتر است ابتدا معماری JavaScript را اصلاح کنیم و تا حد امکان:


External Script

+

Nonce

+

Hash

را بررسی کنیم.

# CSP برای سایت‌های واقعی

فرض کنید سایت از این منابع استفاده می‌کند:


cmsnevis.ir

Google Fonts

YouTube

Analytics

CDN

API

در این حالت نمی‌توانیم یک CSP عمومی را بدون بررسی روی سایت قرار دهیم.

باید ابتدا بفهمیم چه Resourceهایی واقعاً استفاده می‌شوند.

بعد Policy را مرحله به مرحله محدود کنیم.

# CSP Report-Only

یکی از روش‌های مناسب برای تست CSP این است که ابتدا به جای اعمال مستقیم Policy از:


Content-Security-Policy-Report-Only

استفاده کنیم.

مثلاً:


header(

    "Content-Security-Policy-Report-Only: "

    . "default-src 'self'; "

    . "img-src 'self' https: data:; "

    . "script-src 'self';"

);

در این حالت Policy برای گزارش تخلف‌ها استفاده می‌شود، بدون اینکه الزاماً Resource را مسدود کند.

این روش برای پیدا کردن منابعی که ممکن است با CSP واقعی تداخل داشته باشند مفید است.

# Security Headers در آپلود فایل

Security Headers فقط برای صفحه Login نیستند.

مثلاً در سیستم Upload می‌توان از:


X-Content-Type-Options: nosniff

استفاده کرد.

اما این Header جایگزین کنترل‌های Upload نیست.

همچنان باید:

MIME واقعی بررسی شود.
Extension بررسی شود.
نام فایل کنترل شود.
فایل خارج از Web Root ذخیره شود.
اجرای PHP در Upload Directory ممنوع شود.

# Security Headers و XSS

در مقاله XSS دیدیم که باید خروجی را Escape کنیم:


echo htmlspecialchars(

    $name,

    ENT_QUOTES,

    'UTF-8'

);

CSP می‌تواند یک لایه اضافه باشد:


XSS Prevention

       +

CSP

اما نباید بنویسیم:


CSP فعال است

پس Escape لازم نیست.

این کار اشتباه است.

# Security Headers و CSRF

Security Headerها جایگزین CSRF Token نیستند.

برای یک فرم حساس همچنان باید از CSRF Protection استفاده شود.

مثلاً:


CSRF Token

+

SameSite Cookie

+

HTTPS

+

Security Headers

هرکدام نقش متفاوتی دارند.

# Security Headers و Session Cookie

برای Session Cookie نیز می‌توان Attributeهای امنیتی تنظیم کرد.

مثلاً:


session_set_cookie_params([

    'secure' => true,

    'httponly' => true,

    'samesite' => 'Lax',

]);

و سپس:


session_start();

Secure باعث می‌شود Cookie از طریق HTTPS ارسال شود.

HttpOnly دسترسی JavaScript به Cookie را محدود می‌کند.

SameSite نیز در کنترل ارسال Cookie در Contextهای Cross-Site نقش دارد.

# یک نمونه کامل‌تر

می‌توانیم قبل از خروجی صفحه:


<?php



session_set_cookie_params([

    'secure' => true,

    'httponly' => true,

    'samesite' => 'Lax',

]);



session_start();



header(

    'X-Content-Type-Options: nosniff'

);



header(

    'Referrer-Policy: strict-origin-when-cross-origin'

);



header(

    'X-Frame-Options: SAMEORIGIN'

);



header(

    'Permissions-Policy: '

    . 'camera=(), '

    . 'microphone=(), '

    . 'geolocation=()'

);



header(

    'Strict-Transport-Security: max-age=31536000'

);



header(

    "Content-Security-Policy: "

    . "default-src 'self'; "

    . "img-src 'self' data: https:; "

    . "object-src 'none'; "

    . "frame-ancestors 'self';"

);

این فقط یک نمونه پایه است.

# Security Headers را در کجا قرار دهیم؟

سه محل رایج وجود دارد.

۱. PHP

مثلاً:


header(

    'X-Content-Type-Options: nosniff'

);

برای پروژه‌های PHP ساده مناسب است.

۲. Web Server

اگر Apache یا Nginx دارید، می‌توان Headerها را در Web Server تنظیم کرد.

مزیت:

Headerها می‌توانند برای بخش بزرگ‌تری از سایت به صورت متمرکز اعمال شوند.

۳. Framework Middleware

در Frameworkهایی مانند Laravel می‌توان Security Headerها را در Middleware قرار داد.

این روش برای پروژه‌های بزرگ‌تر مدیریت‌پذیرتر است.

# Security Headers در Apache

برای Apache می‌توان از mod_headers استفاده کرد.

مثلاً:


<IfModule mod_headers.c>



    Header always set X-Content-Type-Options "nosniff"



    Header always set Referrer-Policy \

        "strict-origin-when-cross-origin"



    Header always set X-Frame-Options "SAMEORIGIN"



</IfModule>

برای CSP و HSTS باید Policy متناسب با سایت تنظیم شود.

# Security Headers در Nginx

نمونه:


add_header X-Content-Type-Options "nosniff" always;



add_header Referrer-Policy

    "strict-origin-when-cross-origin" always;



add_header X-Frame-Options "SAMEORIGIN" always;

و برای HSTS، فقط در صورتی که HTTPS به شکل صحیح و دائمی فعال است:


add_header Strict-Transport-Security

    "max-age=31536000" always;

# Security Headers در Laravel

در Laravel بهتر است Headerها را در Middleware متمرکز کنیم.

برای مثال:


<?php



namespace App\Http\Middleware;



use Closure;

use Illuminate\Http\Request;



class SecurityHeaders

{

    public function handle(

        Request $request,

        Closure $next

    ) {

        $response = $next($request);



        $response->headers->set(

            'X-Content-Type-Options',

            'nosniff'

        );



        $response->headers->set(

            'Referrer-Policy',

            'strict-origin-when-cross-origin'

        );



        $response->headers->set(

            'X-Frame-Options',

            'SAMEORIGIN'

        );



        return $response;

    }

}

# چگونه Security Headers سایت را بررسی کنیم؟

می‌توانیم Response Headerهای سایت را بررسی کنیم.

با curl:


curl -I https://example.com

مثلاً خروجی ممکن است شامل موارد زیر باشد:


HTTP/2 200



content-type: text/html

x-content-type-options: nosniff

referrer-policy: strict-origin-when-cross-origin

x-frame-options: SAMEORIGIN

این روش برای بررسی سریع مناسب است.

# یک اشتباه رایج: کپی کردن CSP از سایت دیگر

CSP یکی از Headerهایی است که نباید صرفاً Copy/Paste شود.

چون CSP به مواردی مانند:


JavaScript

CSS

Images

Fonts

Frames

Analytics

CDN

API

وابسته است.

Policy مناسب یک سایت ممکن است برای سایت دیگری باعث خراب شدن JavaScript یا تصاویر شود.

# یک اشتباه دیگر: فعال کردن HSTS بدون بررسی HTTPS

این Header:


Strict-Transport-Security

را نباید بدون بررسی زیرساخت فعال کرد.

قبل از آن مطمئن شوید:


HTTPS

✓

Certificate

✓

Redirect

✓

Resources

✓

Subdomains در صورت includeSubDomains

✓

همگی درست هستند.

# آیا Security Headers سرعت سایت را کم می‌کنند؟

خود Headerها معمولاً حجم بسیار کمی دارند.

اما بعضی Policyها مانند CSP می‌توانند باعث شوند Browser منابعی را که در Policy مجاز نیستند Load نکند.

بنابراین باید Policy را دقیق تنظیم و تست کرد.

# چک‌لیست Security Headers

قبل از انتشار پروژه این موارد را بررسی کنید:

[ ] HTTPS فعال است.
[ ] HSTS پس از بررسی کامل HTTPS فعال شده است.
[ ] X-Content-Type-Options: nosniff تنظیم شده است.
[ ] Referrer-Policy مشخص شده است.
[ ] Permissions-Policy بر اساس نیاز پروژه تنظیم شده است.
[ ] Clickjacking با CSP frame-ancestors و/یا X-Frame-Options کنترل شده است.
[ ] CSP متناسب با Resourceهای واقعی سایت تنظیم شده است.
[ ] برای Inline Scriptهای ضروری از Nonce یا روش مناسب دیگری استفاده شده است.
[ ] CSP به عنوان جایگزین XSS Protection استفاده نشده است.
[ ] unsafe-inline بدون بررسی اضافه نشده است.
[ ] Headerها قبل از خروجی ارسال می‌شوند.
[ ] Headerها در یک محل متمرکز مدیریت می‌شوند.
[ ] Policyها روی محیط Staging تست شده‌اند.
[ ] CSP در صورت نیاز ابتدا با Report-Only آزمایش شده است.
[ ] Headerهای قدیمی و غیرضروری بدون دلیل استفاده نشده‌اند.

# پرسش‌های متداول

Security Headers در PHP چیست؟

Security Headers، Headerهای HTTP هستند که به مرورگر می‌گویند صفحه و منابع آن را با چه سیاست‌های امنیتی مدیریت کند.

مهم‌ترین Security Header برای PHP چیست؟

آیا CSP جلوی XSS را می‌گیرد؟

آیا HSTS را روی هر سایتی فعال کنیم؟

آیا `X-Frame-Options` هنوز کاربرد دارد؟

بله، اما برای کنترل دقیق‌تر Frame Ancestors، CSP با frame-ancestors روش مدرن‌تری است.

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

خیر. می‌توان آن‌ها را در PHP، Web Server، Reverse Proxy یا Middleware Framework تنظیم کرد.

# جمع‌بندی

Security Headers یکی از لایه‌های مهم امنیت برنامه‌های وب هستند.

با Headerهایی مانند:


Content-Security-Policy

Strict-Transport-Security

X-Content-Type-Options

Referrer-Policy

Permissions-Policy

X-Frame-Options

با این حال نباید Security Headers را جایگزین اصول اصلی امنیت برنامه بدانیم.

یک پروژه PHP امن همچنان به مواردی مانند:


Prepared Statements

Output Encoding

CSRF Protection

Secure Sessions

Password Hashing

Rate Limiting

2FA

Secure File Upload

نیاز دارد.

Security Headers در PHP چیست؟ آموزش تنظیم هدرهای امنیتی HTTP

۱. PHP

۲. Web Server

۳. Framework Middleware

Security Headers در PHP چیست؟

مهم‌ترین Security Header برای PHP چیست؟

آیا CSP جلوی XSS را می‌گیرد؟

آیا HSTS را روی هر سایتی فعال کنیم؟

آیا `X-Frame-Options` هنوز کاربرد دارد؟

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

مقاله پیشنهادی بعدی

نظرات (0)

مقالات مرتبط

OpenID Connect در PHP چیست؟ آموزش کامل Login با OAuth 2.0 و OIDC

OAuth 2.0 در PHP چیست؟ آموزش کامل Authorization و Access Token

امنیت API در PHP چیست؟ آموزش کامل ساخت API امن از Authentication تا Rate Limiting

CORS در PHP چیست؟ آموزش Cross-Origin Resource Sharing و تنظیم امن API

Security Headers در PHP چیست؟ آموزش تنظیم هدرهای امنیتی HTTP

۱. PHP

۲. Web Server

۳. Framework Middleware

Security Headers در PHP چیست؟

مهم‌ترین Security Header برای PHP چیست؟

آیا CSP جلوی XSS را می‌گیرد؟

آیا HSTS را روی هر سایتی فعال کنیم؟

آیا `X-Frame-Options` هنوز کاربرد دارد؟

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

مقاله پیشنهادی بعدی

نظرات (0)

مقالات مرتبط

OpenID Connect در PHP چیست؟ آموزش کامل Login با OAuth 2.0 و OIDC

OAuth 2.0 در PHP چیست؟ آموزش کامل Authorization و Access Token

امنیت API در PHP چیست؟ آموزش کامل ساخت API امن از Authentication تا Rate Limiting

CORS در PHP چیست؟ آموزش Cross-Origin Resource Sharing و تنظیم امن API

۱. PHP

۲. Web Server

۳. Framework Middleware

Security Headers در PHP چیست؟

مهم‌ترین Security Header برای PHP چیست؟

آیا CSP جلوی XSS را می‌گیرد؟

آیا HSTS را روی هر سایتی فعال کنیم؟

آیا X-Frame-Options هنوز کاربرد دارد؟

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

مقاله پیشنهادی بعدی

نظرات (0)

مقالات مرتبط

OpenID Connect در PHP چیست؟ آموزش کامل Login با OAuth 2.0 و OIDC

OAuth 2.0 در PHP چیست؟ آموزش کامل Authorization و Access Token

امنیت API در PHP چیست؟ آموزش کامل ساخت API امن از Authentication تا Rate Limiting

CORS در PHP چیست؟ آموزش Cross-Origin Resource Sharing و تنظیم امن API

۱. PHP

۲. Web Server

۳. Framework Middleware

Security Headers در PHP چیست؟

مهم‌ترین Security Header برای PHP چیست؟

آیا CSP جلوی XSS را می‌گیرد؟

آیا HSTS را روی هر سایتی فعال کنیم؟

آیا X-Frame-Options هنوز کاربرد دارد؟

آیا Security Headers فقط در PHP تنظیم می‌شوند؟

مقاله پیشنهادی بعدی

نظرات (0)

مقالات مرتبط

OpenID Connect در PHP چیست؟ آموزش کامل Login با OAuth 2.0 و OIDC

OAuth 2.0 در PHP چیست؟ آموزش کامل Authorization و Access Token

امنیت API در PHP چیست؟ آموزش کامل ساخت API امن از Authentication تا Rate Limiting

CORS در PHP چیست؟ آموزش Cross-Origin Resource Sharing و تنظیم امن API

آیا `X-Frame-Options` هنوز کاربرد دارد؟

آیا `X-Frame-Options` هنوز کاربرد دارد؟