فایل security.txt چیست؟ راهنمای ایجاد استاندارد Security.txt برای وب‌سایت

فایل security.txt یک فایل متنی استاندارد برای معرفی راه‌های گزارش آسیب‌پذیری‌های امنیتی وب‌سایت است. این فایل به پژوهشگران امنیت سایبری کمک می‌کند تا در صورت شناسایی مشکلاتی مانند XSS، SQL Injection، نقص احراز هویت یا افشای اطلاعات، بتوانند موضوع را از طریق یک مسیر مشخص و امن به مدیران سایت اطلاع دهند. استاندارد Security.txt در سند RFC 9116 تعریف شده و مسیر اصلی انتشار آن /.well-known/security.txt است.

وجود این فایل به‌تنهایی امنیت وب‌سایت را افزایش نمی‌دهد یا جلوی حملات سایبری را نمی‌گیرد؛ بلکه ارتباط میان پژوهشگران امنیتی و مسئولان سایت را تسهیل می‌کند. در این راهنما با مفهوم Security.txt، ساختار استاندارد آن، فیلدهای ضروری و اختیاری، نحوه ساخت فایل، روش نصب در وردپرس و سرور، اعتبارسنجی، اشتباهات رایج و بهترین روش‌های مدیریت گزارش‌های امنیتی آشنا می‌شوید.

فایل security.txt چیست و چه کاربردی دارد؟

در دنیای امنیت وب، بسیاری از آسیب‌پذیری‌ها ابتدا توسط پژوهشگران مستقل، متخصصان تست نفوذ یا حتی کاربران عادی شناسایی می‌شوند. ممکن است فردی هنگام استفاده از یک فروشگاه اینترنتی متوجه شود که اطلاعات کاربران در شرایط مشخصی به‌اشتباه نمایش داده می‌شود یا یک بخش از سایت از نظر کنترل دسترسی به‌درستی پیکربندی نشده است.

در چنین شرایطی سؤال مهم این است: فرد شناسایی‌کننده آسیب‌پذیری باید مشکل را به چه کسی و از چه طریقی گزارش کند؟

بسیاری از وب‌سایت‌ها تنها یک صفحه تماس با ما دارند که معمولاً برای پشتیبانی مشتریان، مسائل فروش یا درخواست‌های عمومی طراحی شده است. ارسال یک گزارش حساس امنیتی از این مسیر ممکن است باعث شود پیام دیر بررسی شود، به تیم نامرتبط برسد یا اهمیت آن تشخیص داده نشود.

فایل security.txt برای حل بخشی از این مشکل ایجاد شده است.

این فایل یک سند ساده و قابل پردازش توسط ماشین است که اطلاعات مربوط به گزارش آسیب‌پذیری را در قالب فیلدهای مشخص ارائه می‌کند. پژوهشگر با بررسی آن می‌تواند راه ارتباطی مناسب، سیاست افشای آسیب‌پذیری، زبان‌های قابل قبول و در صورت وجود، روش ارسال پیام رمزنگاری‌شده را پیدا کند.

Security.txt چگونه کار می‌کند؟

عملکرد این استاندارد پیچیده نیست. مدیر وب‌سایت یک فایل متنی با نام security.txt می‌سازد و آن را در مسیر مشخصی از دامنه قرار می‌دهد.

برای نمونه، مسیر استاندارد فایل در یک دامنه فرضی به شکل زیر است:

https://example.com/.well-known/security.txt

زمانی که پژوهشگر امنیتی قصد گزارش یک آسیب‌پذیری را دارد، می‌تواند این آدرس را بررسی کند.

در صورت وجود فایل، اطلاعاتی مانند موارد زیر نمایش داده می‌شوند:

• ایمیل مخصوص دریافت گزارش‌های امنیتی
• نشانی فرم امن گزارش آسیب‌پذیری
• تاریخ اعتبار اطلاعات فایل
• نشانی سیاست افشای مسئولانه آسیب‌پذیری
• کلید عمومی رمزنگاری برای مکاتبات محرمانه
• زبان‌های مورد پذیرش برای گزارش‌ها
• صفحه قدردانی از پژوهشگران امنیتی

پژوهشگر سپس می‌تواند از مسیر معرفی‌شده برای ارسال گزارش استفاده کند.

بنابراین Security.txt نقش یک نقطه شروع مشخص برای ارتباطات امنیتی را ایفا می‌کند، نه ابزار اسکن یا سامانه خودکار تشخیص آسیب‌پذیری.

چرا وب‌سایت‌ها به فایل Security.txt نیاز دارند؟

تصور کنید یک متخصص امنیت، آسیب‌پذیری مهمی را در بخش ورود کاربران یک وب‌سایت شناسایی کرده است. او قصد دارد بدون انتشار عمومی اطلاعات حساس، موضوع را به مالک سایت اطلاع دهد.

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

این مسئله می‌تواند چند مشکل ایجاد کند:

1. گزارش در میان پیام‌های عمومی گم شود.
2. اطلاعات حساس به افرادی برسد که مسئول رسیدگی امنیتی نیستند.
3. ارتباط با پژوهشگر به دلیل نبود فرایند مشخص متوقف شود.
4. زمان لازم برای بررسی و رفع آسیب‌پذیری افزایش پیدا کند.
5. پژوهشگر از حدود مجاز بررسی و سیاست افشای سایت اطلاع نداشته باشد.

Security.txt با معرفی کانال مناسب، بخشی از این ابهام را برطرف می‌کند.

البته اثربخشی واقعی آن وابسته به این است که مالک سایت اطلاعات فایل را به‌روز نگه دارد و گزارش‌های دریافتی را بررسی کند.

استاندارد RFC 9116 چیست؟

استاندارد RFC 9116 سندی است که قالب و نحوه استفاده از فایل Security.txt را تعریف می‌کند. این سند در آوریل ۲۰۲۲ توسط Internet Engineering Task Force یا IETF منتشر شد.

عنوان رسمی آن «A File Format to Aid in Security Vulnerability Disclosure» است که به قالبی برای کمک به گزارش آسیب‌پذیری‌های امنیتی اشاره دارد.

RFC 9116 یک سند از نوع Informational است؛ یعنی مشخصات شناخته‌شده‌ای برای هماهنگ‌سازی استفاده از فایل ارائه می‌دهد، اما صرف انتشار آن به این معنا نیست که تمام وب‌سایت‌ها از نظر قانونی ملزم به پیاده‌سازی آن هستند.

هدف اصلی این استاندارد آن است که پژوهشگران و ابزارهای امنیتی بتوانند اطلاعات گزارش آسیب‌پذیری را بدون نیاز به جست‌وجوی پیچیده در صفحات مختلف یک وب‌سایت پیدا کنند.

چرا استانداردسازی گزارش آسیب‌پذیری اهمیت دارد؟

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

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

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

RFC 9116 با معرفی یک قالب استاندارد، امکان شناسایی سریع‌تر اطلاعات را فراهم می‌کند.

برنامه‌های بررسی امنیتی مجاز می‌توانند وجود فایل را بررسی کنند، فیلدهای آن را بخوانند و اطلاعات تماس را استخراج کنند.

بااین‌حال، وجود Security.txt به هیچ فرد یا ابزاری مجوز انجام اسکن تهاجمی، تست نفوذ یا دسترسی به اطلاعات خصوصی نمی‌دهد.

ارتباط Security.txt با افشای هماهنگ آسیب‌پذیری

یکی از مفاهیم مهم در امنیت سایبری، Coordinated Vulnerability Disclosure یا CVD است.

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

این فرایند معمولاً شامل مراحل زیر است:

1. شناسایی اولیه یک مشکل امنیتی
2. یافتن مسیر رسمی گزارش آسیب‌پذیری
3. ارسال اطلاعات لازم بدون افشای غیرضروری داده‌های حساس
4. دریافت و ثبت گزارش توسط تیم مسئول
5. ارزیابی صحت، دامنه و شدت مشکل
6. برنامه‌ریزی و اجرای اصلاحات امنیتی
7. بررسی مجدد رفع مشکل
8. هماهنگی درباره اطلاع‌رسانی عمومی، در صورت نیاز

Security.txt عمدتاً به مرحله یافتن مسیر گزارش کمک می‌کند.

خود فایل جایگزین سیاست CVD، فرایند پاسخ‌گویی به رخداد یا مدیریت آسیب‌پذیری نیست.

محل استاندارد قرارگیری فایل security.txt کجاست؟

یکی از مهم‌ترین نکات هنگام ایجاد Security.txt انتخاب مسیر درست انتشار است.

بر اساس RFC 9116، فایل برای سرویس‌های وب باید در پوشه .well-known قرار گیرد.

آدرس استاندارد به شکل زیر است:

https://example.com/.well-known/security.txt

پوشه .well-known در استانداردهای مختلف وب برای انتشار اطلاعات مشخص و قابل کشف استفاده می‌شود.

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

تفاوت مسیر اصلی و مسیر جایگزین Security.txt

ممکن است هنگام بررسی وب‌سایت‌ها با دو آدرس متفاوت مواجه شوید:

https://example.com/.well-known/security.txt

https://example.com/security.txt

مسیر اول محل استاندارد انتشار بر اساس RFC 9116 است.

مسیر دوم یک مسیر قدیمی یا سازگار با پیاده‌سازی‌های قبلی محسوب می‌شود.

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

بااین‌حال، اگر هر دو مسیر دارای فایل باشند، نسخه موجود در .well-known اولویت دارد.

بهترین روش این است که یک نسخه اصلی معتبر نگهداری شود و مسیر جایگزین به همان نسخه هدایت شود تا اطلاعات متناقض ایجاد نشود.

آیا Security.txt برای زیردامنه‌ها نیز معتبر است؟

به‌صورت پیش‌فرض خیر.

اگر یک وب‌سایت دارای دامنه اصلی و چند زیردامنه باشد، وجود فایل Security.txt روی دامنه اصلی به معنای پوشش خودکار تمام زیردامنه‌ها نیست.

برای مثال:

https://example.com/.well-known/security.txt

این فایل به‌صورت پیش‌فرض برای همان میزبان منتشرکننده معتبر است، نه الزاماً برای:

https://shop.example.com

یا:

https://api.example.com

در صورت نیاز، هر زیردامنه باید فایل استاندارد مربوط به خود را ارائه دهد.

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

همچنین سیاست افشای آسیب‌پذیری باید روشن کند که کدام سامانه‌ها، خدمات و محصولات در محدوده پذیرش گزارش قرار دارند.

ساختار استاندارد فایل security.txt چگونه است؟

Security.txt یک فایل Plain Text یا متن ساده است.

برخلاف اسناد HTML، این فایل به ساختار پیچیده، کدهای JavaScript یا طراحی گرافیکی نیاز ندارد.

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

برای نمونه:

Contact: mailto:[email protected]

در این خط، عبارت Contact نام فیلد و مقدار بعد از علامت دونقطه، روش ارتباط است.

هر فیلد باید در یک خط جداگانه قرار گیرد.

استاندارد از کدگذاری UTF-8 استفاده می‌کند و امکان افزودن خط‌های توضیحی با علامت # نیز وجود دارد.

نمونه ساده و معتبر فایل Security.txt

یک فایل حداقلی می‌تواند ساختاری مانند نمونه زیر داشته باشد:

Contact: mailto:[email protected]
Expires: 2027-04-14T12:00:00Z

این نمونه دارای دو فیلد ضروری است:

• Contact برای معرفی راه ارتباطی
• Expires برای تعیین زمان پایان اعتبار اطلاعات

تاریخ مثال صرفاً برای نمایش قالب است و مدیر سایت باید زمان مناسب را بر اساس تاریخ واقعی انتشار تنظیم کند.

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

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

نمونه کامل‌تر Security.txt برای یک وب‌سایت

نمونه زیر ساختاری گسترده‌تر را نمایش می‌دهد:

# Security vulnerability reporting

Contact: mailto:[email protected]
Contact: https://example.com/security-report

Expires: 2027-04-14T12:00:00Z

Canonical: https://example.com/.well-known/security.txt

Policy: https://example.com/security-policy

Encryption: https://example.com/security-pgp-key.asc

Preferred-Languages: fa, en

Acknowledgments: https://example.com/security-thanks

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

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

پیش از انتشار چنین فایلی باید مطمئن شوید که ایمیل‌ها فعال هستند، صفحات معرفی‌شده وجود دارند، کلید عمومی معتبر است و تاریخ انقضا به‌درستی تنظیم شده است.

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

معرفی تمام فیلدهای مهم فایل Security.txt

برای ایجاد یک فایل قابل اعتماد، لازم است کاربرد هر فیلد را بشناسید.

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

فیلد Contact؛ راه ارتباطی برای گزارش امنیتی

فیلد Contact مهم‌ترین بخش فایل Security.txt است.

این فیلد مشخص می‌کند که پژوهشگران امنیتی گزارش‌های خود را از چه طریقی ارسال کنند.

مقدار آن می‌تواند یک نشانی ایمیل، شماره تماس یا نشانی وب معتبر باشد.

نمونه ایمیل:

Contact: mailto:[email protected]

نمونه فرم گزارش:

Contact: https://example.com/report-security

نمونه شماره تلفن:

Contact: tel:+1-201-555-0123

هنگام معرفی ایمیل باید از پیشوند mailto: استفاده شود.

برای آدرس وب نیز استفاده از HTTPS ضروری است.

امکان ثبت چند فیلد Contact وجود دارد. ترتیب آن‌ها اهمیت دارد و روش ارتباطی ترجیحی باید زودتر قرار گیرد.

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

مهم‌تر از نوع ارتباط، فعال بودن آن است.

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

فیلد Expires؛ تاریخ انقضای اطلاعات

فیلد Expires زمان پایان اعتبار اطلاعات فایل را مشخص می‌کند.

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

نمونه:

Expires: 2027-04-14T12:00:00Z

قالب زمان باید مطابق RFC 3339 باشد.

حرف Z در پایان نمونه نشان‌دهنده زمان UTC است.

هدف از این فیلد جلوگیری از اتکای پژوهشگران به اطلاعات قدیمی است.

ممکن است ایمیل امنیتی یک سازمان تغییر کند، مسئول پاسخ‌گویی جابه‌جا شود یا سیاست گزارش آسیب‌پذیری به‌روزرسانی شود.

اگر فایل تاریخ انقضای مشخصی نداشته باشد، تشخیص اعتبار اطلاعات آن دشوار می‌شود.

استاندارد توصیه می‌کند تاریخ انقضا کمتر از یک سال پس از انتشار فایل باشد.

برای بسیاری از وب‌سایت‌ها انتخاب دوره‌های کوتاه‌تر، مانند چند ماه، همراه با بررسی منظم اطلاعات، گزینه مناسبی است.

البته کوتاه بودن تاریخ انقضا زمانی مفید است که فرایند تمدید آن به‌درستی انجام شود.

فیلد Canonical؛ نشانی معتبر فایل

فیلد Canonical نشانی یا نشانی‌های رسمی فایل Security.txt را معرفی می‌کند.

نمونه:

Canonical: https://example.com/.well-known/security.txt

این فیلد اختیاری است، اما استفاده از آن برای افزایش قابلیت بررسی اصالت فایل توصیه می‌شود.

اگر فایل دارای Canonical باشد و نشانی‌ای که فایل از آن دریافت شده در هیچ‌یک از مقادیر Canonical ذکر نشده باشد، پژوهشگر نباید بدون بررسی بیشتر به محتوای آن اعتماد کند.

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

فیلد Canonical در Security.txt با Canonical مورد استفاده در سئوی صفحات وب تفاوت دارد.

در سئو، تگ Canonical معمولاً برای معرفی نسخه ترجیحی یک صفحه به موتورهای جست‌وجو استفاده می‌شود؛ اما در Security.txt این فیلد به شناسایی نشانی معتبر خود فایل کمک می‌کند.

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

فیلد Policy؛ سیاست افشای آسیب‌پذیری

فیلد Policy نشانی صفحه‌ای را مشخص می‌کند که در آن شرایط و قوانین گزارش آسیب‌پذیری توضیح داده شده است.

نمونه:

Policy: https://example.com/security-policy

وجود این فیلد می‌تواند از سوءتفاهم میان پژوهشگر و مدیر وب‌سایت جلوگیری کند.

یک سیاست مناسب باید موضوعاتی مانند موارد زیر را روشن کند:

• سامانه‌های مجاز برای دریافت گزارش
• روش ارسال آسیب‌پذیری
• اطلاعات مورد نیاز در گزارش
• محدودیت‌های بررسی امنیتی
• رفتارهای غیرمجاز مانند اختلال در سرویس
• نحوه برخورد با اطلاعات شخصی کاربران
• زمان‌بندی مورد انتظار برای پاسخ اولیه
• سیاست انتشار عمومی آسیب‌پذیری
• وضعیت برنامه پاداش یا Bug Bounty

برای مثال، ممکن است سازمان دریافت گزارش درباره آسیب‌پذیری‌های وب‌سایت را بپذیرد، اما هیچ مجوزی برای تست نفوذ فعال صادر نکرده باشد.

صفحه Policy باید این مرز را روشن کند.

فیلد Encryption؛ امکان ارسال گزارش رمزنگاری‌شده

گزارش‌های امنیتی ممکن است حاوی جزئیات حساسی درباره ساختار سامانه، اطلاعات فنی یا شواهد آسیب‌پذیری باشند.

ارسال چنین اطلاعاتی از طریق کانال نامناسب می‌تواند ریسک افشای آن‌ها را افزایش دهد.

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

نمونه:

Encryption: https://example.com/security-pgp-key.asc

این فیلد معمولاً به کلید عمومی OpenPGP اشاره می‌کند.

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

نباید کلید خصوصی در فایل Security.txt یا در یک مسیر عمومی منتشر شود.

همچنین صرف وجود لینک کلید عمومی، اصالت آن را تضمین نمی‌کند. پژوهشگر باید اعتبار و تعلق کلید به سازمان را از مسیرهای قابل اعتماد بررسی کند.

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

فیلد Preferred-Languages؛ زبان‌های قابل قبول

فیلد Preferred-Languages مشخص می‌کند سازمان ترجیح می‌دهد گزارش‌های امنیتی را به چه زبان‌هایی دریافت کند.

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

Preferred-Languages: fa, en

در این نمونه زبان فارسی و انگلیسی معرفی شده‌اند.

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

این فیلد اختیاری است و فقط یک بار می‌تواند در فایل ظاهر شود.

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

در صورت نبود این فیلد، پژوهشگران ممکن است انگلیسی را زبان پیش‌فرض در نظر بگیرند.

بهتر است فقط زبان‌هایی معرفی شوند که تیم مسئول واقعاً توانایی دریافت و رسیدگی به گزارش در آن‌ها را دارد.

فیلد Acknowledgments؛ قدردانی از پژوهشگران

فیلد Acknowledgments به صفحه‌ای اشاره می‌کند که در آن از پژوهشگران امنیتی تقدیر می‌شود.

نمونه:

Acknowledgments: https://example.com/security-thanks

این صفحه می‌تواند نام پژوهشگرانی را نمایش دهد که با گزارش مسئولانه مشکلات امنیتی به بهبود امنیت وب‌سایت کمک کرده‌اند.

البته انتشار نام افراد باید با رضایت آن‌ها انجام شود.

همچنین نباید پیش از رفع آسیب‌پذیری، اطلاعاتی منتشر شود که خطر سوءاستفاده را افزایش دهد.

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

اگر وب‌سایت برنامه Bug Bounty ندارد، بهتر است این موضوع را در سیاست گزارش آسیب‌پذیری شفاف بیان کند.

فیلد Hiring؛ فرصت‌های شغلی امنیت سایبری

فیلد Hiring برای معرفی فرصت‌های شغلی مرتبط با امنیت اطلاعات استفاده می‌شود.

نمونه:

Hiring: https://example.com/security-jobs

این فیلد برای سازمان‌هایی کاربرد دارد که به دنبال جذب پژوهشگران امنیتی، تحلیلگران SOC، متخصصان تست نفوذ یا سایر نیروهای فنی هستند.

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

کدام فیلدها ضروری هستند؟

جدول زیر وضعیت فیلدهای اصلی تعریف‌شده در RFC 9116 را نشان می‌دهد.

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

بهترین فایل الزاماً فایلی نیست که بیشترین تعداد فیلد را داشته باشد؛ بلکه فایلی است که اطلاعات دقیق، معتبر و قابل استفاده ارائه کند.

آموزش ساخت فایل security.txt به‌صورت مرحله‌به‌مرحله

ایجاد فایل Security.txt برای بیشتر وب‌سایت‌ها فرایند ساده‌ای دارد.

در این بخش روش ساخت استاندارد فایل، بدون وابستگی به سیستم مدیریت محتوای خاص، بررسی می‌شود.

مرحله اول: تعیین مسئول دریافت گزارش‌های امنیتی

پیش از ساخت فایل باید مشخص شود چه شخص یا تیمی مسئول دریافت گزارش‌ها است.

برای وب‌سایت‌های کوچک ممکن است این مسئولیت بر عهده مدیر فنی یا توسعه‌دهنده اصلی باشد.

در سازمان‌های بزرگ‌تر معمولاً تیم امنیت اطلاعات، مسئول مدیریت آسیب‌پذیری یا تیم Product Security پاسخ‌گویی را انجام می‌دهد.

بهتر است از یک آدرس سازمانی اختصاصی مانند زیر استفاده شود:

[email protected]

این آدرس باید به صندوقی متصل باشد که به‌صورت منظم بررسی می‌شود.

همچنین لازم است برای زمان‌هایی مانند مرخصی مسئول اصلی یا تغییر نیروی انسانی، جانشین مناسبی تعیین شود.

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

مرحله دوم: ساخت فایل متنی

با استفاده از یک ویرایشگر متن ساده مانند Notepad، VS Code یا ویرایشگرهای متنی لینوکس، فایلی به نام زیر بسازید:

security.txt

توجه داشته باشید که نام فایل دقیق باشد و پسوند دیگری به آن اضافه نشود.

برای مثال، فایل security.txt.txt نام درستی برای این استاندارد نیست.

کدگذاری فایل را روی UTF-8 قرار دهید.

بهتر است در تولید فایل از ویرایشگرهایی استفاده کنید که قالب‌بندی اضافی، کاراکترهای نامرئی نامناسب یا تبدیل خودکار متن به HTML ایجاد نمی‌کنند.

مرحله سوم: افزودن اطلاعات ضروری

ابتدا فیلدهای Contact و Expires را وارد کنید.

برای مثال:

Contact: mailto:[email protected]
Expires: 2027-04-14T12:00:00Z

تاریخ باید در زمان انتشار بررسی و متناسب با برنامه نگهداری فایل تنظیم شود.

اگر چند راه ارتباطی دارید، می‌توانید Contact را چند بار تکرار کنید.

بهتر است راه اصلی ارتباطی در ابتدا نوشته شود.

مرحله چهارم: افزودن فیلدهای تکمیلی

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

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

# Responsible vulnerability disclosure

Contact: mailto:[email protected]

Expires: 2027-04-14T12:00:00Z

Canonical: https://example.com/.well-known/security.txt

Policy: https://example.com/security-policy

Preferred-Languages: fa, en

این نمونه باید پیش از استفاده شخصی‌سازی شود.

در صورتی که صفحه سیاست امنیتی وجود ندارد، بهتر است ابتدا آن را ایجاد کنید یا تا زمان آماده شدن، فیلد Policy را حذف کنید.

مرحله پنجم: ایجاد پوشه .well-known

در مسیر عمومی سرویس وب، پوشه‌ای با نام .well-known ایجاد کنید.

در بسیاری از هاست‌های اشتراکی مبتنی بر cPanel، مسیر ریشه عمومی سایت به شکل زیر است:

public_html

در این شرایط محل فایل معمولاً چنین خواهد بود:

public_html/.well-known/security.txt

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

برای مثال، در برخی سرویس‌ها وب‌سایت از یک زیرپوشه، مسیر Document Root سفارشی یا معماری مبتنی بر کانتینر اجرا می‌شود.

بنابراین محل ذخیره باید بر اساس ریشه واقعی دامنه انتخاب شود.

مرحله ششم: انتشار و بررسی فایل

پس از بارگذاری فایل، نشانی استاندارد را در مرورگر باز کنید.

برای مثال:

https://example.com/.well-known/security.txt

اگر همه‌چیز درست باشد، متن فایل باید نمایش داده شود.

اما مشاهده متن در مرورگر به‌تنهایی برای تأیید کامل کافی نیست.

باید وضعیت پاسخ HTTP، نوع محتوا، اعتبار HTTPS و ساختار فیلدها نیز بررسی شوند.

آموزش ایجاد Security.txt در وردپرس

وردپرس یکی از رایج‌ترین سیستم‌های مدیریت محتوا است و بسیاری از وب‌سایت‌های شرکتی، خبری، آموزشی و فروشگاهی از آن استفاده می‌کنند.

ایجاد فایل Security.txt در وردپرس معمولاً با دو روش امکان‌پذیر است:

1. ساخت دستی فایل در هاست
2. استفاده از افزونه سازگار با استاندارد

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

روش اول: ساخت دستی Security.txt در هاست وردپرس

روش دستی برای مدیرانی مناسب است که به File Manager یا سرویس انتقال فایل امن دسترسی دارند.

ابتدا وارد پنل مدیریت هاست شوید.

اگر از cPanel استفاده می‌کنید، بخش File Manager را باز کنید.

سپس مسیر ریشه عمومی دامنه وردپرسی را پیدا کنید.

در بسیاری از نصب‌های معمول، این مسیر public_html است.

در آنجا پوشه .well-known را ایجاد کنید.

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

این نکته اهمیت دارد، زیرا ممکن است سرویس‌های دیگر نیز از مسیر .well-known استفاده کنند.

سپس فایل security.txt را داخل پوشه قرار دهید.

محتوای آن را ویرایش و ذخیره کنید.

در پایان، آدرس فایل را از طریق HTTPS بررسی کنید.

مزیت اصلی روش دستی این است که برای انتشار یک فایل کوچک به افزونه اضافی نیاز ندارید.

از طرف دیگر، به‌روزرسانی و تمدید تاریخ اعتبار آن معمولاً باید توسط مسئول سایت انجام شود.

روش دوم: استفاده از افزونه وردپرس

برخی افزونه‌های وردپرس امکان ایجاد و مدیریت Security.txt را از داخل پیشخوان فراهم می‌کنند.

یکی از نمونه‌های منتشرشده در مخزن رسمی وردپرس، افزونه Generate Security.txt است.

چنین افزونه‌هایی می‌توانند فرایند ورود اطلاعات و ارائه فایل در مسیر مناسب را ساده‌تر کنند.

برای استفاده از یک افزونه باید ابتدا موارد زیر را بررسی کنید:

• سازگاری افزونه با نسخه فعلی وردپرس
• وضعیت نگهداری و به‌روزرسانی
• اعتبار توسعه‌دهنده
• کیفیت کدنویسی و سطح دسترسی مورد نیاز
• پشتیبانی از مسیر استاندارد
• پشتیبانی از فیلدهای ضروری RFC 9116
• امکان تنظیم تاریخ انقضا
• نحوه تولید فایل و پاسخ HTTP

پس از نصب، اطلاعات تماس و سایر فیلدها را بر اساس امکانات افزونه وارد کنید.

سپس خروجی واقعی سایت را بررسی کنید.

نصب افزونه به معنای تضمین صحت فایل نیست؛ ممکن است تنظیمات کش، افزونه امنیتی یا قوانین سرور بر دسترسی به فایل تأثیر بگذارند.

آیا ساخت Security.txt بدون افزونه بهتر است؟

برای سایتی که تنها به یک فایل ثابت نیاز دارد و مدیر آن به هاست دسترسی دارد، روش دستی می‌تواند ساده‌تر باشد.

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

در مقابل، افزونه برای تیم‌هایی که مدیریت فایل‌های سرور را انجام نمی‌دهند یا ترجیح می‌دهند تنظیمات از داخل پیشخوان انجام شود، ممکن است مناسب‌تر باشد.

نکته مهم این است که استفاده از افزونه‌های متعدد و غیرضروری خود می‌تواند هزینه نگهداری و سطح پیچیدگی وردپرس را افزایش دهد.

هیچ ضرورتی ندارد صرفاً برای ساخت Security.txt یک افزونه جدید نصب شود.

نکات امنیتی ویژه وردپرس

اگر قصد دارید فایل Security.txt را به یک سایت وردپرسی اضافه کنید، بهتر است موارد زیر نیز بررسی شوند:

• دسترسی فایل از مسیر استاندارد توسط افزونه‌های امنیتی مسدود نشده باشد.
• قوانین محافظت از فایل‌های مخفی، دسترسی به پوشه .well-known را مختل نکنند.
• سیستم کش نسخه منقضی‌شده فایل را ارائه ندهد.
• فایل پس از انتقال سایت به دامنه جدید به‌روزرسانی شود.
• آدرس‌های داخل فایل به دامنه واقعی سایت اشاره کنند.
• دریافت گزارش‌های امنیتی از مسیر مناسب و امن انجام شود.
• اطلاعات تماس امنیتی به حساب‌های شخصی و غیرقابل مدیریت وابسته نباشد.

همچنین به خاطر داشته باشید که Security.txt جایگزین به‌روزرسانی هسته وردپرس، افزونه‌ها، قالب‌ها یا سایر اقدامات امنیتی نیست.

آموزش راه‌اندازی Security.txt در سرور لینوکس

در سرورهای لینوکسی می‌توان فایل را مستقیماً در Document Root وب‌سایت قرار داد.

محل دقیق این پوشه به نوع وب‌سرور و تنظیمات میزبانی بستگی دارد.

برای مثال، ممکن است یک سرور Nginx یا Apache از مسیر اختصاصی مربوط به دامنه استفاده کند.

ایجاد پوشه و فایل

اگر ریشه عمومی یک وب‌سایت فرضی مسیر /var/www/example.com/public باشد، محل انتشار فایل چنین خواهد بود:

/var/www/example.com/public/.well-known/security.txt

مدیر سرور می‌تواند پوشه مورد نیاز را ایجاد کند و فایل را با ویرایشگر متنی مناسب بنویسد.

باید دسترسی خواندن عمومی فایل از طریق وب‌سرور فراهم باشد، اما تغییر آن فقط برای کاربران و فرایندهای مجاز امکان‌پذیر باشد.

نیازی نیست برای عمومی شدن فایل، مجوز نوشتن همگانی به آن اختصاص داده شود.

سطح دسترسی فایل و مالکیت آن باید با مدل امنیتی همان سرور هماهنگ باشد.

تنظیم صحیح Content-Type

یکی از الزامات فنی استاندارد، ارائه فایل با نوع محتوای مناسب است.

مقدار مورد انتظار:

Content-Type: text/plain; charset=utf-8

این مقدار به مرورگر و ابزارهای پردازش‌کننده اعلام می‌کند که محتوای دریافتی یک فایل متنی ساده با کدگذاری UTF-8 است.

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

مدیر سرور باید تنظیمات MIME و پاسخ نهایی فایل را بررسی کند.

اطمینان از فعال بودن HTTPS

Security.txt باید از طریق HTTPS قابل دریافت باشد.

HTTPS با استفاده از TLS به محافظت از ارتباط میان دریافت‌کننده و سرور کمک می‌کند.

اگر فایل فقط روی HTTP در دسترس باشد، با الزام استاندارد برای انتشار وبی مطابقت ندارد.

علاوه بر فعال بودن HTTPS، اعتبار گواهی TLS و صحت نام دامنه نیز اهمیت دارد.

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

بررسی پاسخ سرور

پس از انتشار فایل، می‌توان از ابزارهای HTTP برای مشاهده وضعیت پاسخ و هدرها استفاده کرد.

برای نمونه، دستور زیر هدرهای پاسخ را درخواست می‌کند:

curl -I https://example.com/.well-known/security.txt

نتیجه مطلوب معمولاً شامل وضعیت موفق و نوع محتوای صحیح است.

بااین‌حال، برخی سرورها درخواست HEAD را متفاوت از GET پردازش می‌کنند. بنابراین در صورت مشاهده نتیجه غیرمنتظره، باید درخواست دریافت واقعی فایل نیز بررسی شود.

برای مشاهده هدرها همراه با محتوای پاسخ می‌توان از دستور زیر استفاده کرد:

curl -i https://example.com/.well-known/security.txt

این بررسی برای وب‌سایت یا سروری که مالک آن هستید یا مسئول مدیریت آن محسوب می‌شوید، روشی ساده برای کنترل انتشار فایل است.

ساخت Security.txt در وب‌سایت‌های دارای CDN و Cloudflare

بسیاری از وب‌سایت‌ها از شبکه توزیع محتوا یا CDN استفاده می‌کنند.

CDN می‌تواند فایل‌های ثابت را کش کند و درخواست‌ها را پیش از رسیدن به سرور اصلی پردازش کند.

اگر Security.txt پشت CDN قرار داشته باشد، باید مطمئن شوید نسخه صحیح و به‌روز آن به کاربران ارائه می‌شود.

مشکلات احتمالی کش

یکی از مشکلات رایج زمانی رخ می‌دهد که مدیر سایت فایل را به‌روزرسانی می‌کند، اما CDN همچنان نسخه قدیمی را نمایش می‌دهد.

این مسئله به‌خصوص هنگام تغییر ایمیل امنیتی یا تمدید تاریخ Expires اهمیت پیدا می‌کند.

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

برای جلوگیری از این وضعیت بهتر است:

• سیاست کش فایل به‌صورت مشخص بررسی شود.
• پس از تغییرات مهم، کش مربوط به مسیر فایل پاک‌سازی شود.
• نسخه دریافتی از CDN با نسخه اصلی مقایسه شود.
• تاریخ اعتبار فایل به‌صورت دوره‌ای کنترل شود.

تنظیمات امنیتی CDN

برخی تنظیمات امنیتی CDN ممکن است برای درخواست‌های خاص، صفحه تأیید مرورگر یا چالش ضدربات نمایش دهند.

اگر چنین پاسخی برای Security.txt ایجاد شود، ابزارهای خودکار ممکن است به جای فایل متنی، صفحه HTML دریافت کنند.

بهتر است مسیر استاندارد فایل به‌گونه‌ای پیکربندی شود که درخواست‌های عادی و غیرمخرب بتوانند آن را دریافت کنند.

البته این موضوع به معنای غیرفعال کردن حفاظت امنیتی برای کل دامنه نیست.

هر استثنا باید محدود به مسیر مورد نیاز و متناسب با سیاست امنیتی وب‌سایت باشد.

تفاوت Security.txt با robots.txt، sitemap.xml و فایل htaccess

یکی از اشتباهات رایج، یکسان در نظر گرفتن فایل‌های شناخته‌شده وب‌سایت است.

درحالی‌که Security.txt، robots.txt، sitemap.xml و تنظیمات htaccess اهداف متفاوتی دارند.

آیا Security.txt مانند robots.txt اجباری است؟

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

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

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

آیا Security.txt در سئوی سایت تأثیر مستقیم دارد؟

وجود فایل Security.txt به‌خودی‌خود یک عامل رتبه‌بندی شناخته‌شده و اثبات‌شده در گوگل نیست.

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

مزیت اصلی این استاندارد در حوزه مدیریت امنیت و گزارش آسیب‌پذیری است.

البته رسیدگی مناسب به مشکلات امنیتی می‌تواند به حفظ سلامت فنی، دسترس‌پذیری و اعتماد کاربران کمک کند؛ عواملی که برای عملکرد بلندمدت یک وب‌سایت مهم هستند.

بنابراین نباید Security.txt را به‌عنوان یک ترفند سئو معرفی کرد.

آیا انتشار فایل Security.txt امنیت سایت را افزایش می‌دهد؟

پاسخ به این سؤال نیازمند تفکیک دو مفهوم است: امنیت فنی و مدیریت گزارش‌های امنیتی.

Security.txt به‌صورت مستقیم آسیب‌پذیری‌ها را شناسایی یا برطرف نمی‌کند.

این فایل مانند WAF، سیستم تشخیص نفوذ یا ابزار بررسی بدافزار عمل نمی‌کند.

اما می‌تواند به افزایش کارآمدی فرایند مدیریت آسیب‌پذیری کمک کند.

مزیت اول: تسهیل گزارش آسیب‌پذیری

زمانی که مسیر گزارش مشخص باشد، پژوهشگر لازم نیست برای پیدا کردن مسئول امنیتی زمان زیادی صرف کند.

این مسئله می‌تواند احتمال رسیدن گزارش به فرد مناسب را افزایش دهد.

مزیت دوم: کاهش سردرگمی در ارتباطات امنیتی

اگر گزارش‌های امنیتی از کانال مشخصی دریافت شوند، دسته‌بندی و پیگیری آن‌ها ساده‌تر خواهد بود.

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

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

وجود لینک Policy به پژوهشگران کمک می‌کند روش مورد انتظار سازمان برای ارسال و افشای اطلاعات را بشناسند.

این موضوع می‌تواند زمینه ارتباط منظم‌تری را فراهم کند.

مزیت چهارم: امکان خودکارسازی

از آنجا که Security.txt یک قالب قابل پردازش توسط ماشین دارد، سازمان‌ها و ابزارهای مجاز می‌توانند اطلاعات گزارش آسیب‌پذیری را به‌صورت ساختاریافته دریافت کنند.

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

محدودیت مهم Security.txt

حتی کامل‌ترین فایل Security.txt نیز نمی‌تواند مانع حملاتی مانند Brute Force، CSRF، XSS یا SQL Injection شود.

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

ارتباط Security.txt با برنامه Bug Bounty چیست؟

برنامه Bug Bounty سازوکاری است که طی آن یک سازمان ممکن است در برابر گزارش آسیب‌پذیری‌های معتبر و مشمول شرایط برنامه، پاداش مالی یا غیرمالی پرداخت کند.

اما Security.txt صرفاً یک قالب برای معرفی اطلاعات گزارش آسیب‌پذیری است.

وجود فایل به معنای فعال بودن برنامه Bug Bounty نیست.

تفاوت سیاست افشای آسیب‌پذیری و برنامه پاداش

سیاست افشای آسیب‌پذیری یا Vulnerability Disclosure Policy مشخص می‌کند افراد چگونه می‌توانند مشکلات امنیتی را گزارش کنند و چه قواعدی باید رعایت شود.

برنامه Bug Bounty علاوه بر تعیین قواعد، معمولاً شرایط دریافت پاداش، دارایی‌های مجاز و معیارهای پذیرش را نیز تعریف می‌کند.

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

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

در هر دو حالت می‌توان از Security.txt استفاده کرد.

آیا Security.txt مجوز تست نفوذ است؟

خیر.

این نکته یکی از مهم‌ترین ملاحظات استاندارد است.

وجود Security.txt هیچ مجوز ضمنی برای بررسی تهاجمی، دسترسی غیرمجاز، استخراج داده، اسکن مخرب یا ایجاد اختلال در سرویس صادر نمی‌کند.

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

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

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

چگونه یک سیاست افشای آسیب‌پذیری مناسب تهیه کنیم؟

برای استفاده حرفه‌ای از Security.txt بهتر است یک صفحه مستقل برای سیاست گزارش امنیتی ایجاد شود.

این صفحه مکمل فایل است و جزئیات بیشتری را در اختیار پژوهشگران قرار می‌دهد.

مشخص کردن محدوده دارایی‌های مشمول

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

برای مثال، ممکن است دامنه اصلی و اپلیکیشن رسمی شرکت مشمول سیاست باشند، اما سرویس‌های شخص ثالث خارج از محدوده قرار گیرند.

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

تعیین رفتارهای غیرمجاز

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

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

هدف از این محدودیت‌ها محافظت از کاربران و پایداری سامانه است.

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

مشخص کردن اطلاعات مورد نیاز در گزارش

برای بررسی سریع‌تر گزارش، می‌توان از پژوهشگر درخواست کرد اطلاعاتی مانند موارد زیر را ارائه دهد:

• نشانی بخش آسیب‌پذیر
• شرح واضح مشکل
• شرایط مشاهده آسیب‌پذیری
• اثر احتمالی بر محرمانگی، یکپارچگی یا دسترس‌پذیری
• اطلاعات فنی لازم برای بازتولید کنترل‌شده
• زمان تقریبی مشاهده مشکل
• اطلاعات تماس پژوهشگر، در صورت تمایل

نباید پژوهشگر را به جمع‌آوری غیرضروری اطلاعات شخصی یا ادامه آزمایش‌های پرخطر تشویق کرد.

تعیین زمان‌بندی پاسخ‌گویی

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

برای مثال، ممکن است یک تیم متعهد شود در روزهای کاری طی چند روز به گزارش‌های معتبر پاسخ اولیه بدهد.

بااین‌حال، چنین زمان‌بندی باید با ظرفیت واقعی تیم مطابقت داشته باشد.

وعده‌هایی که قابل اجرا نیستند می‌توانند اعتماد پژوهشگران را کاهش دهند.

همچنین زمان پاسخ اولیه با زمان رفع نهایی آسیب‌پذیری یکسان نیست.

رفع یک مشکل پیچیده ممکن است به بررسی فنی، تغییر معماری، آزمایش و استقرار نسخه جدید نیاز داشته باشد.

امضای دیجیتال Security.txt چیست و چه اهمیتی دارد؟

یکی از خطرات احتمالی در انتشار Security.txt تغییر غیرمجاز محتوای آن است.

اگر مهاجمی به وب‌سایت دسترسی پیدا کند، ممکن است بتواند فایل را نیز تغییر دهد و اطلاعات تماس را به آدرس تحت کنترل خود منتقل کند.

در این حالت، گزارش‌های حساس امنیتی احتمال دارد به جای سازمان اصلی برای مهاجم ارسال شوند.

برای کاهش این خطر، RFC 9116 استفاده از امضای دیجیتال OpenPGP را توصیه می‌کند.

امضای OpenPGP چگونه به اعتبار فایل کمک می‌کند؟

امضای دیجیتال امکان بررسی این موضوع را فراهم می‌کند که محتوای فایل پس از امضا تغییر نکرده و امضا با کلید مربوط سازگار است.

اگر پژوهشگر به کلید عمومی امضاکننده اعتماد داشته باشد، می‌تواند اصالت فایل را با اطمینان بیشتری بررسی کند.

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

همچنین امضای دیجیتال نمی‌تواند تمام انواع سوءاستفاده را به‌تنهایی متوقف کند.

برای مثال، اگر کلید خصوصی امضا نیز در اختیار مهاجم قرار گیرد، قابلیت اعتماد به امضا آسیب می‌بیند.

تفاوت امضای دیجیتال و رمزنگاری گزارش

امضای دیجیتال و رمزنگاری دو کاربرد متفاوت دارند.

امضای دیجیتال عمدتاً برای بررسی اصالت و یکپارچگی محتوا استفاده می‌شود.

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

در Security.txt فیلد Encryption محل دریافت کلید رمزنگاری را معرفی می‌کند، درحالی‌که امضای دیجیتال می‌تواند خود فایل را امضا کند.

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

آیا امضای دیجیتال اجباری است؟

خیر.

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

برای سایت‌های کوچک، انتشار فایل صحیح با Contact فعال و Expires معتبر نقطه شروع مناسبی است.

سازمان‌هایی که سطح بالاتری از اعتمادپذیری نیاز دارند می‌توانند فرایند امضای فایل، نگهداری امن کلید خصوصی و اعتبارسنجی دوره‌ای را نیز پیاده‌سازی کنند.

چگونه اعتبار فایل Security.txt را بررسی کنیم؟

پس از ساخت و انتشار فایل، لازم است صحت آن بررسی شود.

این مرحله اهمیت زیادی دارد، زیرا ممکن است فایل از نظر ظاهری درست باشد اما با الزامات استاندارد مطابقت نداشته باشد.

بررسی مسیر انتشار

ابتدا مسیر زیر را باز کنید:

https://example.com/.well-known/security.txt

فایل باید از طریق HTTPS و بدون نیاز به ورود به حساب کاربری در دسترس باشد.

در حالت معمول انتظار می‌رود سرور وضعیت HTTP 200 را بازگرداند.

وجود تغییر مسیر لزوماً به معنای نامعتبر بودن فایل نیست، اما مقصد تغییر مسیر و ارتباط آن با منبع اصلی باید قابل بررسی باشد.

بررسی فیلدهای ضروری

اطمینان حاصل کنید که دست‌کم یک فیلد Contact معتبر وجود دارد.

همچنین فیلد Expires باید دقیقاً یک بار وارد شده و تاریخ آن هنوز نگذشته باشد.

اگر چند راه تماس تعریف کرده‌اید، ترتیب آن‌ها را بررسی کنید.

اگر Preferred-Languages را اضافه کرده‌اید، نباید چند نسخه از این فیلد در فایل وجود داشته باشد.

بررسی فرمت و کدگذاری

فایل باید متن ساده با کدگذاری UTF-8 باشد.

مقادیر باید از قالب‌های معتبر استفاده کنند.

برای مثال، قرار دادن ایمیل بدون mailto: در فیلد Contact با ساختار مورد انتظار مطابقت ندارد.

همچنین درج یک تاریخ مبهم یا تاریخ فاقد قالب معتبر می‌تواند باعث خطای اعتبارسنجی شود.

بررسی لینک‌های معرفی‌شده

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

برای مثال:

• آیا صفحه Policy در دسترس است؟
• آیا فرم Contact به‌درستی کار می‌کند؟
• آیا فایل کلید عمومی واقعاً وجود دارد؟
• آیا نشانی Canonical صحیح است؟
• آیا صفحه Acknowledgments معتبر است؟

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

استفاده از ابزار اعتبارسنجی

وب‌سایت رسمی securitytxt.org امکان تولید فایل و بررسی اطلاعات استاندارد را فراهم می‌کند.

همچنین ابزارهای مستقلی برای اعتبارسنجی ساختار RFC 9116 وجود دارند.

هنگام استفاده از سرویس‌های آنلاین، بهتر است از اعتبار سرویس مطمئن شوید و از ارسال اطلاعات محرمانه غیرضروری خودداری کنید.

با توجه به عمومی بودن ماهیت Security.txt، خود فایل نباید حاوی کلید خصوصی، رمز عبور یا اطلاعات داخلی حساس باشد.

چک‌لیست بررسی فایل Security.txt

پیش از انتشار نهایی یا پس از هر تغییر مهم، می‌توان از چک‌لیست زیر استفاده کرد.

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

اشتباهات رایج هنگام ساخت فایل Security.txt

بسیاری از خطاهای Security.txt به دلیل پیچیدگی فنی نیستند؛ بلکه از بی‌توجهی به جزئیات کوچک ایجاد می‌شوند.

اشتباه اول: قرار دادن فایل فقط در ریشه سایت

یکی از خطاهای متداول قرار دادن فایل تنها در آدرس زیر است:

https://example.com/security.txt

اگرچه این مسیر برای سازگاری قدیمی قابل استفاده است، اما مسیر اصلی مطابق RFC 9116 باید زیر .well-known باشد.

بهتر است نسخه استاندارد در محل اصلی منتشر شود.

اشتباه دوم: استفاده از تاریخ انقضای گذشته

یک فایل ممکن است همچنان در سرور موجود باشد، اما تاریخ اعتبار آن پایان یافته باشد.

در چنین وضعیتی پژوهشگر نباید به‌سادگی به اطلاعات قدیمی اعتماد کند.

برای جلوگیری از این مشکل، تمدید تاریخ باید بخشی از برنامه نگهداری وب‌سایت باشد.

اشتباه سوم: معرفی ایمیل غیرفعال

گاهی مدیر سایت یک ایمیل اختصاصی امنیتی تعریف می‌کند، اما هیچ‌کس آن را بررسی نمی‌کند.

این وضعیت ممکن است باعث از دست رفتن گزارش‌های مهم شود.

بهتر است امکان دریافت پیام، ارسال پاسخ و دسترسی مسئولان مربوط به‌صورت دوره‌ای آزمایش شود.

اشتباه چهارم: قرار دادن اطلاعات محرمانه در فایل

Security.txt عمومی است و هر فردی می‌تواند آن را مشاهده کند.

بنابراین نباید اطلاعاتی مانند رمز عبور، کلید خصوصی، توکن API، مشخصات داخلی شبکه یا اطلاعات شخصی غیرضروری را در آن قرار داد.

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

اشتباه پنجم: استفاده نادرست از Canonical

اگر آدرس فایل تغییر کرده باشد اما مقدار Canonical همچنان به دامنه یا مسیر قدیمی اشاره کند، بررسی اعتبار محتوا دشوار می‌شود.

این موضوع به‌خصوص هنگام انتقال دامنه، تغییر ساختار میزبانی یا استفاده از چند میزبان اهمیت دارد.

اشتباه ششم: اشتباه گرفتن Security.txt با ابزار محافظتی

برخی مدیران ممکن است تصور کنند ساخت Security.txt باعث جلوگیری از حملات یا بسته شدن آسیب‌پذیری‌ها می‌شود.

درحالی‌که این فایل یک ابزار ارتباطی است.

اگر سایت دارای افزونه آسیب‌پذیر، رمز عبور ضعیف یا نقص کنترل دسترسی باشد، Security.txt به‌تنهایی مشکل را برطرف نمی‌کند.

اشتباه هفتم: استفاده از افزونه نامعتبر

نصب یک افزونه صرفاً برای تولید یک فایل متنی، بدون بررسی کیفیت و وضعیت امنیتی آن، ممکن است وابستگی غیرضروری ایجاد کند.

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

اشتباه هشتم: نداشتن سیاست پاسخ‌گویی

انتشار فایل بدون تعیین مسئول رسیدگی، مانند نصب صندوق پستی است که هیچ فردی نامه‌های آن را بررسی نمی‌کند.

برای مفید بودن Security.txt، سازمان باید فرایندی برای ثبت، ارزیابی، پیگیری و بستن گزارش‌ها داشته باشد.

مدیریت گزارش‌های دریافتی از طریق Security.txt

پس از راه‌اندازی فایل، مرحله مهم‌تر آغاز می‌شود: رسیدگی به گزارش‌های امنیتی.

یک فرایند ساده اما منظم می‌تواند حتی برای وب‌سایت‌های کوچک مفید باشد.

دریافت و ثبت گزارش

در زمان دریافت پیام، بهتر است گزارش در یک سیستم پیگیری داخلی یا ابزار مدیریت درخواست ثبت شود.

اطلاعات پایه می‌تواند شامل تاریخ دریافت، شناسه گزارش، نام یا نام مستعار پژوهشگر، سامانه مرتبط و وضعیت بررسی باشد.

اطلاعات حساس باید فقط در اختیار افراد مسئول قرار گیرد.

بررسی اولیه و دسته‌بندی

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

سپس می‌توان نوع آسیب‌پذیری را مشخص کرد.

برای نمونه:

• نقص کنترل دسترسی
• آسیب‌پذیری XSS
• ضعف مدیریت نشست
• پیکربندی ناامن سرور
• نقص اعتبارسنجی ورودی
• افشای ناخواسته اطلاعات
• آسیب‌پذیری مرتبط با احراز هویت

این دسته‌بندی به انتخاب مسئول مناسب برای بررسی کمک می‌کند.

ارزیابی شدت آسیب‌پذیری

شدت آسیب‌پذیری باید بر اساس اثر واقعی، شرایط بهره‌برداری، دارایی آسیب‌دیده و زمینه سامانه تعیین شود.

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

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

برای مثال، یک ضعف ظاهراً محدود در بخش پرداخت ممکن است از نظر کسب‌وکار اهمیت بالایی داشته باشد.

رفع مشکل و بررسی مجدد

پس از تأیید گزارش، اصلاحات باید در محیط مناسب توسعه و آزمایش شوند.

ممکن است رفع مشکل به تغییر کد، تنظیم مجوزها، اصلاح پیکربندی یا به‌روزرسانی یک مؤلفه نیاز داشته باشد.

پس از اصلاح، لازم است بررسی شود که مشکل اصلی رفع شده و تغییرات باعث ایجاد اختلال جدید نشده‌اند.

در صورت امکان می‌توان نتیجه را از طریق کانال امن با پژوهشگر هماهنگ کرد.

اطلاع‌رسانی و بستن گزارش

پس از اطمینان از رفع مشکل، سازمان می‌تواند وضعیت نهایی را به پژوهشگر اعلام کند.

اگر سیاست انتشار عمومی آسیب‌پذیری وجود دارد، زمان و سطح جزئیات انتشار باید با در نظر گرفتن امنیت کاربران تعیین شود.

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

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

بهترین روش‌های نگهداری و مدیریت Security.txt

ساخت فایل تنها مرحله ابتدایی است.

برای حفظ اعتبار آن باید برنامه نگهداری مشخصی وجود داشته باشد.

بررسی دوره‌ای اطلاعات

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

برای بسیاری از سایت‌ها یک بررسی ماهانه یا فصلی متناسب با میزان تغییرات سازمان می‌تواند مناسب باشد.

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

کنترل تغییرات فایل

در سازمان‌هایی که از Git یا سامانه‌های مدیریت پیکربندی استفاده می‌کنند، می‌توان Security.txt را همراه سایر فایل‌های زیرساخت مدیریت کرد.

مزیت این روش، امکان ثبت تاریخچه تغییرات و بررسی اصلاحات توسط افراد مسئول است.

همچنین بهتر است تغییرات غیرمنتظره فایل پایش شوند.

محدود کردن دسترسی نوشتن

ازآنجاکه فایل عمومی است، نیازی به مخفی کردن محتوای آن وجود ندارد.

اما دسترسی تغییر فایل باید محدود باشد.

اگر کاربران یا فرایندهای غیرمجاز بتوانند محتوای Security.txt را تغییر دهند، امکان جایگزینی اطلاعات تماس وجود خواهد داشت.

استفاده از مجوزهای مناسب فایل، مدیریت حساب‌های سرور و کنترل فرایند استقرار اهمیت دارد.

تعیین جانشین مسئول امنیتی

اگر مسئول اصلی پاسخ‌گویی برای مدتی در دسترس نباشد، گزارش‌ها نباید بدون رسیدگی باقی بمانند.

بهتر است حداقل یک فرد یا تیم جایگزین برای بررسی پیام‌ها مشخص باشد.

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

نگهداری تاریخچه گزارش‌ها

ثبت گزارش‌های گذشته به شناسایی الگوهای تکرارشونده کمک می‌کند.

برای مثال، اگر در چند ماه متوالی مشکلات کنترل دسترسی گزارش شوند، ممکن است نیاز به بازبینی معماری مجوزها یا آزمون‌های امنیتی گسترده‌تر وجود داشته باشد.

هدف از نگهداری این اطلاعات، بهبود امنیت سازمان است.

دسترسی به مستندات حساس باید محدود و دوره نگهداری آن‌ها مشخص باشد.

Security.txt برای چه وب‌سایت‌هایی مناسب است؟

تقریباً هر وب‌سایتی که مسیر مشخصی برای دریافت گزارش‌های آسیب‌پذیری نیاز دارد می‌تواند از Security.txt استفاده کند.

بااین‌حال، اهمیت عملی این فایل برای بعضی کسب‌وکارها بیشتر است.

فروشگاه‌های اینترنتی

فروشگاه‌های اینترنتی معمولاً اطلاعات حساب کاربران، سفارش‌ها، نشانی‌ها و فرایندهای پرداخت را مدیریت می‌کنند.

در چنین سامانه‌هایی دریافت سریع گزارش مشکلات امنیتی می‌تواند اهمیت بالایی داشته باشد.

برای فروشگاه‌های مبتنی بر WooCommerce نیز امکان انتشار Security.txt مانند سایر سایت‌های وردپرسی وجود دارد.

سامانه‌های مالی و خدمات پرداخت

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

وجود یک کانال گزارش رسمی می‌تواند بخشی از برنامه مدیریت آسیب‌پذیری سازمان باشد.

البته چنین سامانه‌هایی به کنترل‌های امنیتی جامع‌تری نیز نیاز دارند.

سرویس‌های SaaS و پلتفرم‌های آنلاین

سرویس‌های نرم‌افزاری آنلاین معمولاً چندین مؤلفه مانند وب‌سایت، API، پنل کاربری و سرویس‌های پشتیبان دارند.

در این محیط‌ها بهتر است محدوده هر دارایی و سیاست دریافت گزارش به‌وضوح مشخص باشد.

سایت‌های شرکتی و سازمانی

وب‌سایت‌های سازمانی نیز ممکن است دارای فرم‌های تماس، پنل‌های مدیریتی و اطلاعات داخلی باشند.

Security.txt می‌تواند یک مسیر ارتباطی رسمی برای پژوهشگران فراهم کند.

وب‌سایت‌های شخصی و وبلاگ‌ها

حتی یک وب‌سایت کوچک هم می‌تواند از فایل حداقلی Security.txt استفاده کند.

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

برای یک سایت شخصی، یک ایمیل فعال و اطلاعات دقیق معمولاً مفیدتر از تعریف مجموعه‌ای از فیلدهای غیرضروری است.

سؤالات متداول درباره فایل security.txt

فایل security.txt چیست؟

Security.txt یک فایل متنی استاندارد برای معرفی روش‌های گزارش آسیب‌پذیری‌های امنیتی وب‌سایت است. این فایل به پژوهشگران کمک می‌کند راه ارتباطی مسئول امنیتی و سیاست افشای آسیب‌پذیری را پیدا کنند.

محل قرارگیری فایل Security.txt کجاست؟

مسیر استاندارد آن /.well-known/security.txt است. فایل باید از طریق HTTPS در دامنه مربوط در دسترس باشد.

آیا ساخت Security.txt برای تمام سایت‌ها اجباری است؟

خیر. RFC 9116 یک مشخصات استاندارد از نوع Informational است و به‌خودی‌خود برای تمام وب‌سایت‌ها الزام قانونی عمومی ایجاد نمی‌کند. بااین‌حال، ممکن است برخی سازمان‌ها بر اساس سیاست‌های داخلی یا الزامات خاص ملزم به استفاده از آن باشند.

آیا Security.txt امنیت وردپرس را افزایش می‌دهد؟

این فایل به‌صورت مستقیم آسیب‌پذیری‌های وردپرس را برطرف نمی‌کند. کاربرد اصلی آن تسهیل دریافت گزارش‌های امنیتی است و باید در کنار سایر کنترل‌های امنیتی استفاده شود.

آیا فایل Security.txt روی سئو تأثیر دارد؟

هیچ تأثیر مستقیم تضمین‌شده‌ای بر رتبه‌بندی موتورهای جست‌وجو برای آن شناخته نشده است. هدف اصلی این فایل مدیریت ارتباطات مربوط به آسیب‌پذیری است.

آیا می‌توان Security.txt را بدون افزونه وردپرس ساخت؟

بله. کافی است یک فایل متنی استاندارد ایجاد کنید و آن را در مسیر .well-known ریشه عمومی سایت قرار دهید. سپس دسترسی و صحت محتوا را بررسی کنید.

آیا درج ایمیل شخصی در Security.txt مناسب است؟

ترجیحاً از ایمیل اختصاصی سازمانی استفاده کنید. ایمیل شخصی ممکن است مشکلاتی مانند وابستگی به یک فرد، دشواری انتقال مسئولیت و افزایش پیام‌های ناخواسته ایجاد کند.

آیا فایل Security.txt به کلید PGP نیاز دارد؟

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

تاریخ Expires باید چقدر باشد؟

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

آیا وجود Security.txt به پژوهشگران مجوز تست نفوذ می‌دهد؟

خیر. فایل Security.txt به‌تنهایی هیچ مجوزی برای تست نفوذ یا فعالیت تهاجمی ایجاد نمی‌کند. محدوده فعالیت مجاز باید از طریق مجوزهای معتبر و سیاست‌های سازمان مشخص شود.

آیا یک فایل برای تمام زیردامنه‌ها کافی است؟

به‌صورت پیش‌فرض خیر. فایل فقط برای میزبان یا آدرس مشخصی که از آن دریافت شده معتبر است. زیردامنه‌ها باید جداگانه بررسی شوند و در صورت نیاز، فایل مربوط به خود را ارائه دهند.

اگر فایل Security.txt منقضی شود چه اتفاقی می‌افتد؟

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

آیا می‌توان چند ایمیل در فایل قرار داد؟

بله. می‌توان چند فیلد Contact تعریف کرد. ترتیب آن‌ها باید نشان‌دهنده روش‌های ترجیحی تماس باشد.

آیا Security.txt جایگزین صفحه تماس با ما است؟

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

آیا استفاده از فایل Security.txt خطر امنیتی دارد؟

انتشار صحیح آن معمولاً خطر خاصی ایجاد نمی‌کند، اما اطلاعات نادرست، تغییر غیرمجاز فایل یا معرفی کانال ارتباطی ناامن می‌تواند مشکل‌ساز شود. بنابراین کنترل دسترسی، اعتبارسنجی و نگهداری منظم اهمیت دارند.

جمع‌بندی

فایل security.txt یکی از ساده‌ترین روش‌ها برای ایجاد یک مسیر استاندارد و قابل شناسایی جهت گزارش آسیب‌پذیری‌های امنیتی وب‌سایت است. این فایل با استفاده از قالب تعریف‌شده در RFC 9116 به پژوهشگران امنیت سایبری کمک می‌کند راه ارتباطی مناسب، سیاست افشای آسیب‌پذیری و در صورت وجود، روش ارسال اطلاعات رمزنگاری‌شده را پیدا کنند.

برای ساخت یک فایل استاندارد، وجود فیلدهای Contact و Expires ضروری است. همچنین استفاده از مسیر /.well-known/security.txt، انتشار از طریق HTTPS، ارائه محتوای متنی UTF-8 و بررسی صحت اطلاعات اهمیت دارد.

مدیران سایت‌های وردپرسی می‌توانند این فایل را به‌صورت دستی یا با استفاده از افزونه مناسب ایجاد کنند. مدیران سرور نیز باید دسترسی صحیح، نوع محتوا و وضعیت پاسخ HTTP را بررسی کنند.

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

در نهایت، Security.txt یک ابزار ارتباطی برای مدیریت مسئولانه آسیب‌پذیری‌ها است، نه جایگزین اقدامات امنیتی فنی. ترکیب این استاندارد با به‌روزرسانی منظم، کنترل دسترسی، احراز هویت امن، پایش امنیتی و مدیریت اصولی گزارش‌ها می‌تواند به ایجاد فرایندی قابل اعتمادتر برای حفاظت از وب‌سایت و کاربران کمک کند.