Content Security Policy (CSP): amaliy muhandislik qo‘llanmasi

Content Security Policy: amaliy muhandislik qo‘llanmasi

Content Security Policy (CSP) — brauzer tomonidan qo‘llanadigan xavfsizlik mexanizmi bo‘lib, saytga qaysi resurslar yuklanishi yoki bajarilishi mumkinligini va xavfsizlik bilan bog‘liq qaysi harakatlarga ruxsat berilishini belgilash imkonini beradi. Uning eng muhim amaliy vazifasi cross-site scripting (XSS) oqibatlarini kamaytirishdir: zararli HTML sahifaga kirib qolgan taqdirda ham, kuchli CSP kiritilgan JavaScript kodining bajarilishini to‘sishi mumkin. CSP Level 3 — W3C spetsifikatsiyasining amaldagi yo‘nalishi; 2026-yil sentabr holatiga ko‘ra u hali ham Working Draft bo‘lib, W3C’ning joriy drafti 2026-yil 13-avgust sanasi bilan berilgan. (w3.org)

CSP’ni to‘g‘ri escaping, sanitization, xavfsiz templating yoki XSS zaifliklarini tuzatishning o‘rnini bosuvchi vosita deb qarash kerak emas. Bu defense in depth — brauzer tomonidan majburiy qo‘llanadigan qo‘shimcha himoya qatlami. (web.dev)

CSP nima?

Content Security Policy odatda Content-Security-Policy HTTP response header orqali yuboriladi:

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

Bu brauzerga default-src tomonidan boshqariladigan resurslar odatda sahifaning o‘zi joylashgan origin’dan yuklanishi kerakligini bildiradi.

Policy bir nechta directive’dan iborat bo‘lishi mumkin. Har biri alohida imkoniyatni boshqaradi:

default-src ko‘plab fetch directive’lar uchun fallback vazifasini bajaradi. Masalan, img-src bo‘lmasa, rasmlar default-src qoidalariga tushishi mumkin. Ammo bu qoida hamma directive’ga tegishli emas: masalan, frame-ancestors, form-action va base-uri default-src qiymatini meros qilib olmaydi. (w3.org)

CSP nega muhim?

Tasavvur qiling, zaif sahifa hujumchi boshqaradigan HTML’ni tasodifan chiqarib yuboradi:

<script>
  stealSession();
</script>

Qo‘shimcha himoya bo‘lmasa, brauzer bu kodni bajarishi mumkin.

Kuchli CSP savolni:

“Bu to‘g‘ri JavaScript kodimi?”

degan holatdan:

“Bu sahifa aynan shu JavaScript bajarilishiga ruxsat berganmi?”

degan holatga o‘zgartiradi.

Aynan shu sababli CSP ko‘plab XSS zaifliklarining ta’sirini sezilarli kamaytirishi mumkin.

Asosiy murakkablik — qaysi script’lar ishonchli hisoblanishini belgilashda.

Eski CSP konfiguratsiyalari ko‘pincha domain allowlist’ga tayanardi:

script-src 'self' https://cdn.example.com

Bu istalgan script’ga ruxsat berishdan yaxshiroq, lekin katta host-based allowlist’larni tushunish va xavfsiz boshqarish qiyinlashadi. Bundan tashqari, ayrim ruxsat berilgan origin’lar o‘zlari ham hujumchi boshqaradigan kodni bajarish imkonini berishi mumkin. Shu sabab zamonaviy CSP tavsiyalari script bajarilishini boshqarishda nonce yoki hash asosidagi strict CSP’ni afzal ko‘radi. (developer.mozilla.org)

Strict CSP

Nonce asosidagi oddiy strict policy quyidagicha ko‘rinishi mumkin:

Content-Security-Policy:
  script-src 'nonce-RANDOM_VALUE' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Bu yerda asosiy element — nonce.

Server har bir response uchun yangi, oldindan taxmin qilib bo‘lmaydigan qiymat yaratadi:

<script nonce="RANDOM_VALUE" src="/app.js"></script>

Xuddi shu qiymat CSP header ichida ham bo‘ladi:

script-src 'nonce-RANDOM_VALUE'

Qiymatlar mos kelgani uchun brauzer script’ni bajaradi. To‘g‘ri nonce bo‘lmagan kiritilgan script esa bloklanadi.

Bu yondashuv haqiqiy himoya berishi uchun nonce oldindan taxmin qilib bo‘lmaydigan bo‘lishi va har bir response uchun yangidan yaratilishi kerak. web.dev kriptografik jihatdan kuchli, imkon qadar kamida 128 bit qiymatdan foydalanishni tavsiya qiladi. (web.dev)

Nonce’ni application ishga tushganda bir marta yaratib, keyin doimiy ishlatmang. O‘zgarmaydigan nonce bir martalik authorization token sifatidagi ma’nosini yo‘qotadi.

Nonce va hash

Nonce va hash o‘xshash muammoni hal qiladi, lekin turli arxitekturalarga mos keladi.

Nonce odatda dinamik rendering qilinadigan HTML uchun qulayroq. Server har bir request paytida yangi qiymat yaratadi va uni ruxsat berilgan <script> elementlariga qo‘shadi.

Hash esa barqaror yoki statik generatsiya qilingan HTML uchun qulay. Tasodifiy qiymat yaratish o‘rniga, ruxsat berilgan script uchun cryptographic hash hisoblanadi:

script-src 'sha256-AbCdEf...'

Brauzer script’ning hash qiymatini hisoblaydi va faqat policy’dagi qiymat bilan mos kelsa bajaradi.

CSP SHA-256, SHA-384 va SHA-512 hash source expression’larini qo‘llab-quvvatlaydi. Inline script ichidagi juda kichik o‘zgarish ham uning hash qiymatini o‘zgartiradi, shu sabab hash-based CSP ishlatadigan build system’lar script tarkibi o‘zgarganda policy’ni qayta generatsiya qilishi kerak bo‘ladi. MDN tashqi script’larni hash orqali ruxsatlashda qo‘shimcha talablar, jumladan mos integrity attribute kerakligini ham hujjatlashtiradi. (developer.mozilla.org)

SSR application uchun nonce ko‘pincha soddaroq muhandislik yechimi bo‘ladi. Har bir response’da HTML’ni o‘zgartirish istalmaydigan statik saytlar uchun esa hash qulayroq bo‘lishi mumkin.

strict-dynamic qanday ishlaydi?

Zamonaviy application’lar ko‘pincha boshqa script’larni dinamik yuklaydigan ishonchli bootstrap script’dan foydalanadi.

Qo‘shimcha sozlama bo‘lmasa, ikkilamchi script’lar bloklanishi mumkin.

Quyidagini qo‘shish:

'strict-dynamic'

to‘g‘ri nonce yoki hash orqali berilgan ishonchni shu trusted script yuklaydigan script’larga ham uzatish imkonini beradi. (developer.mozilla.org)

Masalan:

script-src 'nonce-abc123' 'strict-dynamic'

va:

<script nonce="abc123" src="/bootstrap.js"></script>

/bootstrap.js bajarilishiga ruxsat beradi va u keyinchalik yaratib, yuklaydigan script’larga ham ruxsat berishi mumkin.

Bu yerda muhim oqibat bor: CSP Level 3 semantikasini qo‘llaydigan brauzerlarda 'strict-dynamic' to‘g‘ri nonce/hash ishonchi bilan ishlatilsa, script-src ichidagi 'self', https: va aniq host allowlist kabi host expression’lar e’tiborga olinmaydi. Natijada trusted script chain’ning o‘zi muhim xavfsizlik chegarasiga aylanadi. (developer.mozilla.org)

Agar trusted JavaScript hujumchi boshqarishi mumkin bo‘lgan input asosida script URL’larini dinamik yaratsa, CSP bunday arxitekturani avtomatik ravishda tuzatib bera olmaydi.

Amaliy policy

Real application odatda faqat script-src bilan cheklanmaydi.

Masalan:

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-{NONCE}' 'strict-dynamic';
  style-src 'self';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  object-src 'none';
  base-uri 'none';
  form-action 'self';
  frame-ancestors 'none';

Buni har bir saytga o‘zgartirmasdan ko‘chirib qo‘yiladigan tayyor policy emas, balki arxitektura misoli sifatida ko‘rish kerak.

Masalan, frame-ancestors 'none' boshqa sahifalarning ushbu document’ni embed qilishini taqiqlaydi va UI-redressing hujumlaridan himoyalanishga yordam berishi mumkin. Ammo customer saytlariga ataylab embed qilinadigan application uchun aniq parent origin’larni ruxsatlash kerak bo‘lishi mumkin. Bu directive default-src’dan meros olmaydi, shuning uchun zarur bo‘lsa alohida ko‘rsatilishi kerak. (w3.org)

Xuddi shunday, connect-src ichida application amalda ishlatadigan API, WebSocket endpoint va boshqa network manzillar bo‘lishi kerak.

Maqsad imkon qadar uzun CSP yaratish emas. Maqsad — application’ning qonuniy xatti-harakatlarini imkon qadar aniq va tor doirada ifodalash.

unsafe-inline dan saqlaning

CSP xatolariga keng tarqalgan javoblardan biri:

script-src 'self' 'unsafe-inline'

Bu ko‘pincha CSP’ning eng muhim himoya imkoniyatlaridan birini zaiflashtiradi, chunki ixtiyoriy inline JavaScript bajarilishiga ruxsat berilishi mumkin.

Yaxshiroq yondashuv — bunday pattern’larni:

<button onclick="save()">Save</button>

JavaScript event registration’ga o‘tkazish:

<button id="save">Save</button>

<script nonce="{NONCE}">
document
  .getElementById('save')
  .addEventListener('click', save);
</script>

Strict CSP odatda href="javascript:..." kabi JavaScript URL’larni ham to‘sadi va 'unsafe-eval' ochiq ruxsat berilmagan bo‘lsa, eval() kabi string’ni code sifatida bajaradigan mexanizmlarni bloklaydi. (web.dev)

Shu sabab 'unsafe-inline' yoki 'unsafe-eval' ni faqat CSP xatolarini yo‘qotish uchun qo‘shish standart yechim emas, balki muammoni tekshirishga sabab bo‘lishi kerak.

Report-Only bilan bosqichma-bosqich joriy qiling

Strict policy’ni production’da to‘g‘ridan-to‘g‘ri yoqish analytics, payment widget’lar, authentication flow’lar, customer support tool’lar, API request’lar yoki CSP hisobga olinmay yozilgan application code’ni buzishi mumkin.

Quyidagidan foydalaning:

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'nonce-{NONCE}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Report-only mode policy’ni tekshiradi, lekin bloklashni majburiy qo‘llamaydi. Brauzer console xabarlari va CSP report’lar proposed policy real holatda nimani bloklashini ko‘rsatadi. (developer.mozilla.org)

Amaliy rollout quyidagicha ko‘rinadi:

Kuzatish → violation’larni tasniflash → qonuniy dependency’larni tuzatish → policy’ni kuchaytirish → enforcement’ni yoqish → monitoring’ni davom ettirish.

Report’da chiqqan har bir hostname’ni avtomatik ravishda allowlist’ga qo‘shmang. Violation eski kod, kutilmagan third-party dependency, browser extension, injection urinish yoki haqiqiy konfiguratsiya talabini ko‘rsatishi mumkin.

CSP Reporting

Zamonaviy CSP reporting Reporting API, Reporting-Endpoints header va CSP’dagi report-to directive’dan foydalanadi:

Reporting-Endpoints:
  csp="https://example.com/csp-reports"

Content-Security-Policy:
  default-src 'self';
  report-to csp;

CSP Level 3’da report-uri report-to foydasiga deprecated deb hisoblanadi. Shunga qaramay, MDN’ning amaldagi yo‘riqnomasida report-to’ni to‘liq qo‘llamaydigan brauzerlar bilan moslik kerak bo‘lgan holatlarda ikkala variant ham ko‘rsatiladi. (w3.org)

Report’larning o‘zini ham ishonchsiz input deb hisoblash kerak. Logging infrastructure har bir report’ga ishonib ketmasligi, balki uni validate qilishi, rate-limit qo‘llashi va xavfsiz saqlashi kerak.

Header yoki <meta>

CSP’ni quyidagicha ham berish mumkin:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'self'"
>

lekin production uchun odatda HTTP header afzal.

Meta orqali berilgan CSP’da muhim cheklovlar mavjud. U report-only policy bera olmaydi, CSP Level 3 esa frame-ancestors, report-uri va sandbox kabi directive’lar meta mexanizmi orqali qo‘llab-quvvatlanmasligini belgilaydi. Bundan tashqari, meta policy brauzer uni uchratishidan oldin qayta ishlangan resurslarni orqaga qarab boshqara olmaydi. (w3.org)

CSP’dagi keng tarqalgan xatolar

Eng ko‘p uchraydigan muhandislik xatolari syntax bilan emas, trust model bilan bog‘liq: juda katta hostname ro‘yxatini kuchli himoya deb hisoblash, nonce qiymatlarini qayta ishlatish, har bir violation’dan keyin domain’larni avtomatik qo‘shish, xatolarni yo‘qotish uchun 'unsafe-inline' ni yoqish yoki default-src 'none' frame-ancestors va form-action kabi directive’larni ham avtomatik sozlaydi deb o‘ylash.

Yana bir nozik xato — bir nechta CSP policy yuborib, ikkinchisi birinchisini yumshatadi deb kutish. Bir nechta enforced policy birgalikda qo‘llanadi: request barcha tegishli policy talablariga javob berishi kerak. Ikkinchi header oldingi qat’iy policy’ni shunchaki override qila olmaydi. (w3.org)

SeoNest tavsiyasi

Generic CSP generator natijasini ko‘chirib olishdan ko‘ra, application’ning real resource graph’idan boshlang.

Dinamik rendering qilinadigan application’lar uchun har bir response’da to‘g‘ri generatsiya qilinadigan nonce va strict script-src afzal. Statik application’lar uchun hash-based policy’ni ko‘rib chiqish mumkin. object-src, base-uri, form-action va frame-ancestors kabi xavfsizlikka sezgir directive’larni product’ning real talablariga mos ravishda aniq belgilang.

Avval proposed policy’ni report-only mode’da ishga tushiring, violation’larni tekshiring, mos kelmaydigan JavaScript pattern’larni olib tashlang va shundan keyingina enforcement’ni yoqing.

Eng muhimi, CSP’ning xavfsizlik modelidagi o‘rnini to‘g‘ri tushunish kerak: bu brauzer tomonidan majburiy qo‘llanadigan containment mexanizmi, XSS zaifliklarini tuzatmasdan qoldirish uchun ruxsat emas.

FAQ

CSP barcha XSS hujumlarini to‘xtatadimi?

Yo‘q. CSP script bajarilishini sezilarli cheklashi va ko‘plab XSS zaifliklarining ta’sirini kamaytirishi mumkin, ammo trusted script’larning o‘zi ekspluatatsiya qilinadigan xatti-harakatni taqdim etsa, bypass’lar hali ham mumkin. Input handling, context-aware output encoding, sanitization va xavfsiz application dizayni baribir zarur. (web.dev)

Har bir sayt default-src 'none' ishlatishi kerakmi?

Har doim emas. Bu kuchli boshlang‘ich yondashuv, chunki undan keyin resurslarni ataylab ruxsatlash kerak bo‘ladi, ammo yakuniy directive’lar baribir application arxitekturasiga mos bo‘lishi kerak. Ayrim directive’lar default-src qiymatini meros qilmaydi.

Nonce yoki hash — qaysi birini ishlatish kerak?

Agar server har bir response uchun HTML generatsiya qilib, uni o‘zgartira olsa, nonce ishlating. Barqaror statik HTML uchun hash ko‘pincha qulayroq. (developer.mozilla.org)

CSP’ni Nginx’da sozlash mumkinmi?

Ha. Nginx CSP header’larini yuborishi mumkin, ammo nonce-based CSP odatda application yoki rendering layer bilan hamkorlikni talab qiladi, chunki yangi nonce bir vaqtning o‘zida response header’da ham, ruxsat berilgan HTML ichida ham bo‘lishi kerak.

CSP ishlayotganini qanday tekshiraman?

Amaldagi response header’larni tekshiring, application’dagi kutilgan flow’larni sinab ko‘ring, browser DevTools’da CSP violation’larni kuzating, report-only davrida report’larni to‘plang, ataylab taqiqlangan resurslarni sinab ko‘ring va enforcement yoqilgandan keyin testlarni takrorlang.

Yakuniy xulosa

Foydali CSP shunchaki trusted domain’lar ro‘yxati emas. Bu brauzer tomonidan majburiy qo‘llanadigan aniq trust model.

Ko‘plab zamonaviy application’lar uchun eng kuchli amaliy yondashuv — cryptographic nonce yoki hash asosidagi strict policy va framing, form submission, plugin hamda boshqa resurslarni cheklaydigan directive’lardan foydalanish. Uni bosqichma-bosqich joriy qiling, enforcement’dan oldin violation’larni o‘lchang va har bir istisnoni ro‘yxatga yana bitta hostname qo‘shish emas, balki arxitektura qarori sifatida ko‘ring.

Manbalar

1. W3C — Content Security Policy Level 3, Working Draft, August 13, 2026. (w3.org) W3C CSP Level 3 specification
2. MDN Web Docs — Content Security Policy (CSP), accessed September 19, 2026. (developer.mozilla.org) MDN CSP Guide
3. MDN Web Docs — Content-Security-Policy header, accessed September 19, 2026. (developer.mozilla.org) MDN CSP Header Reference
4. web.dev — Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP), accessed September 19, 2026. (web.dev) web.dev Strict CSP Guide
5. MDN Web Docs — Content Security Policy implementation, accessed September 19, 2026. (developer.mozilla.org) MDN CSP Implementation Guide
6. MDN Web Docs — frame-ancestors directive, accessed September 19, 2026. (developer.mozilla.org) MDN frame-ancestors Reference
7. MDN Web Docs — Content-Security-Policy-Report-Only, accessed September 19, 2026. (developer.mozilla.org) MDN CSP Report-Only Reference

Tahririyat qaydlari

SEO TITLE: Content Security Policy (CSP): amaliy muhandislik qo‘llanmasi

META DESCRIPTION: Content Security Policy qanday ishlashi, strict CSP’da nonce va hash’dan qanday foydalanish, uni xavfsiz joriy qilish, violation’larni aniqlash va keng tarqalgan CSP xatolaridan qochishni o‘rganing.

SUGGESTED SLUG:content-security-policy-csp-guide

PRIMARY SEARCH INTENT: CSP’ni tushunish va amaliy Content Security Policy’ni loyihalash, joriy qilish, test qilish hamda xavfsiz ishga tushirishni o‘rganish.

PRIMARY ENTITY: Content Security Policy (CSP)

PARENT ENTITY: Web Application Security

RELATED ENTITIES:

• Cross-Site Scripting (XSS)
• CSP Level 3
• script-src
• default-src
• nonce
• cryptographic hash
• strict-dynamic
• frame-ancestors
• report-to
• Reporting API
• Trusted Types
• Subresource Integrity

SUGGESTED INTERNAL LINKS:

• INTERNAL LINK: Cross-Site Scripting nima?
• INTERNAL LINK: HTTP Security Headers Explained
• INTERNAL LINK: Subresource Integrity Explained
• INTERNAL LINK: HSTS Explained
• INTERNAL LINK: Reverse Proxy Architecture

SUGGESTED CHILD ARTICLES:

• CSP Nonces Explained
• CSP Hashes Explained
• strict-dynamic Explained
• CSP Reporting and report-to
• CSP for Nuxt Applications
• CSP for Symfony Applications
• CSP With Nginx

SUGGESTED SIBLING ARTICLES:

• HSTS Explained
• CORS Explained
• Same-Origin Policy Explained
• Subresource Integrity Explained
• Trusted Types Explained

VISUAL OPPORTUNITIES:HTML → CSP policy → allowed resource / blocked resource oqimini ko‘rsatadigan oddiy browser-request diagrammasi; HTTP header va ruxsat berilgan <script> elementida bir xil tasodifiy qiymatni ko‘rsatadigan nonce flow; hamda domain allowlist CSP bilan nonce/hash asosidagi strict CSP’ni taqqoslaydigan ixcham diagramma. Generic hacker, laptop, neon code yoki cybersecurity stock tasvirlaridan foydalanmaslik kerak.

PROGRAMMATIC EXPANSION: CSP implementatsiyasi haqiqatda farq qiladigan joylarda framework’ga xos alohida sahifalar yaratish asosli: CSP × Nuxt, CSP × Symfony, CSP × Next.js, CSP × Nginx va CSP × Cloudflare.

ORIGINAL RESEARCH OPPORTUNITIES: SeoNest production framework’larni strict CSP bilan test qilib, qaysi default’lar inline script generatsiya qilishi, unsafe-eval talab qilishi, avtomatik nonce qo‘llab-quvvatlashi yoki third-party dependency’lar sabab kutilmagan CSP violation yaratishini hujjatlashtirishi mumkin.

BRIEF BASIS: Mavzu, til, dalillar ierarxiyasi, chuqurlik, publication structure va tahririyat talablari taqdim etilgan SeoNest brief’iga asoslangan.