Sayt uchun HTTP xavfsizlik sarlavhalari chek-listi

Qisqacha javob

Xavfsizlik sarlavhalari — server har bir javob bilan yuboradigan ko‘rsatmalar, ular brauzerga qo‘shimcha himoyani yoqishni buyuradi. Ular koddagi xatolarni tuzatmaydi, lekin hujumlarning butun sinflarini yo‘qotadi va biror narsa o‘tib ketsa, zararni cheklaydi. Sozlash bir necha daqiqa oladi, asosiy ish — hech narsa buzilmaganini tekshirish.

Chek-list

Izohlar

• HSTS faqat HTTPS orqali ishlaydi va uni tez bekor qilib bo‘lmaydi, shuning uchun max-age bosqichma-bosqich oshiriladi.
• CSP — eng kuchli sarlavha va buzilishlarning eng ehtimoliy manbai. Content-Security-Policy-Report-Only dan boshlang va asta-sekin qat’iylashtiring.
• X-Frame-Options — eski mexanizm; zamonaviy brauzerlarda uni CSP’dagi frame-ancestors almashtiradi. Ikkalasini yuborish normal holat, shunda eski mijozlar ham qamrab olinadi.
• Referrer-Policy: tavsiya etilgan qiymat zamonaviy brauzerlarda allaqachon standart, lekin uni aniq belgilash brauzerlar orasidagi farqlardan himoya qiladi va maxfiy sahifalarda siyosatni qat’iylashtirishga imkon beradi (no-referrer).
• Permissions-Policy: bo‘sh ro‘yxat () funksiyani sahifangiz va barcha freymlar uchun o‘chiradi.

Cookie’lar ham sarlavha

Sessiya yoki token uchun har bir Set-Cookie quyidagilarni o‘z ichiga olishi kerak:

• Secure — faqat HTTPS orqali yuboriladi;
• HttpOnly — JavaScript uchun ko‘rinmaydi, shuning uchun XSS uni o‘qiy olmaydi;
• SameSite=Lax (yoki Strict) — ko‘pchilik saytlararo so‘rovlar bilan yuborilmaydi, bu CSRF xavfini kamaytiradi.

Nimani olib tashlash va nimani ishlatmaslik kerak

• Versiya raqami bilan Server va X-Powered-By — hujumchi uchun bepul inventarizatsiya. nginx’da server_tokens off, ko‘pchilik freymvorklarda X-Powered-Byni o‘chirish opsiyasi bor.
• X-XSS-Protection — u boshqargan filtr zamonaviy brauzerlardan olib tashlangan va o‘zi muammolar keltirib chiqarishi mumkin edi. Uni yubormang yoki 0 qo‘ying, CSP’ga tayaning.
• Public-Key-Pins (HPKP) va Expect-CT — eskirgan. HPKP esa foydalanuvchilarga saytga kirishni butunlay to‘sib qo‘yishi mumkin edi.

nginx uchun misol

Umumiy sarlavhalarni bitta faylga chiqaring va uni har bir serverga hamda o‘zining add_headeri bor har bir locationga ulang — aks holda nginx ularni u yerda meros qilib olmaydi.

# /etc/nginx/snippets/security-headers.conf
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;

server {
    listen 443 ssl;
    server_tokens off;
    include snippets/security-headers.conf;
}

Agar sayt CDN ortida tursa yoki sarlavhalarni freymvork bersa, ziddiyatli qiymatli dublikatlar bo‘lmasligi uchun ularni bitta joyda belgilang.

Qanday tekshirish kerak

1. Buyruqlar qatori: curl -sI https://example.com javob sarlavhalarini chiqaradi.
2. Brauzer DevTools: Network yorlig‘i → hujjat → Response Headers. Konsolda CSP va Permissions-Policy buzilishlarini kuzating.
3. Onlayn skanerlar: Mozilla HTTP Observatory va securityheaders.com baho qo‘yadi va har bir yetishmayotgan sarlavhani tushuntiradi.
4. Turli sahifa turlarini tekshiring: bosh sahifa, API javobi, statik fayl, 404 sahifasi va redirekt. Xatolar va statik fayllarda sarlavhalar ko‘pincha yo‘qolib qoladi.