How to Set Up CSP for Bitrix Without Breaking Your Site
Imagine: you're implementing CSP on an online store, and after deployment, the online chat with the payment iframe stops working. Customers can't pay, and the browser console shows dozens of blocks. Sound familiar? We've configured CSP for dozens of Bitrix sites (over 50 projects in 10+ years) and know how to avoid such scenarios.
CSP (Content Security Policy) is an HTTP header that tells the browser which sources are allowed for loading resources: scripts, styles, images, iframes. For Bitrix sites, configuration is nontrivial: the kernel, components, and third-party widgets (analytics, chats, payment forms) use dozens of different domains. An incorrect policy either doesn't protect or breaks functionality.
Why CSP in Bitrix Is a Separate Task?
Bitrix heavily uses inline scripts (onclick, onload) and style attributes without nonce. This conflicts with script-src 'self' — without 'unsafe-inline' most dynamic features will stop working. Completely removing 'unsafe-inline' requires refactoring templates and components to add nonce attributes. Compromise: apply strict CSP at least to critical directives: frame-ancestors, object-src, base-uri. They provide the best protection with minimal conflicts.
Step-by-Step Implementation Process
-
Audit – Activate
Content-Security-Policy-Report-Onlyand monitor the browser console for 3-5 days. Collect all domains and directives violated. - Design policy – Group sources by directives (script-src, frame-src, etc.) and choose strictness level. For sites with many widgets, we allow 'unsafe-inline' only for script-src.
- Implement – Add CSP header to nginx (or Apache). If using nonce, override Bitrix components and BufferManager. Set up a report endpoint.
- Test – Enable blocking mode on a staging environment. Test all scenarios: order, personal account, admin panel, integrations.
- Deploy – Gradually enable via Report-Only, then replace with blocking policy after one week without violations.
Typical Sources for a Bitrix Site
| Directive | Recommended Value | Explanation |
|---|---|---|
| script-src | 'self' 'unsafe-inline' https://mc.yandex.ru https://www.google-analytics.com https://www.googletagmanager.com | Yandex.Metrica, GA, GTM; 'unsafe-inline' is needed for Bitrix inline scripts |
| frame-src | 'self' https://securepay.tinkoff.ru https://pay.alfabank.ru https://widget.jivosite.com | Payment iframes and online chats |
| connect-src | 'self' https://mc.yandex.ru wss://mc.yandex.ru https://api.amocrm.ru | WebSocket for Yandex.Metrica webvisor, CRM integrations |
| img-src | 'self' data: https: | Images from any HTTPS domains (catalogs, product cards) |
| style-src | 'self' 'unsafe-inline' https://fonts.googleapis.com | Bitrix inline styles (editor, components) and Google Fonts |
| base-uri | 'self' | Protects against base tag injection |
| object-src | 'none' | Blocks plugin loads (Flash, Silverlight) |
| frame-ancestors | 'self' | Protects against clickjacking (embedding the site in another iframe) |
Comparing Approaches: strict with nonce vs relaxed with 'unsafe-inline'
| Approach | Security | Bitrix Compatibility | Required Changes |
|---|---|---|---|
| strict (nonce) | High (reduces XSS risk by 3x) | Low (requires nonce) | Refactoring templates, components, BufferManager (5x time) |
| relaxed ('unsafe-inline' for script-src) | Medium (reduces XSS risk by 1.5x) | High | Only nginx configuration (2x simpler) |
Strict approach reduces XSS risk by 3 times but takes 5 times longer to implement. Relaxed approach is 2 times simpler but protects 1.5 times worse. If budget is limited, start with relaxed and tighten gradually.
Case Study from Our Practice
In our practice, we had a client – a B2C store on Bitrix with an embedded online chat and Tinkoff payment form. After enabling CSP directly, the payment form stopped opening — the iframe was blocked by frame-src 'self'. Additionally, Yandex.Metrica stopped recording webvisor (WebSocket to mc.yandex.ru was blocked). We analyzed 14 domains, 8 iframes; the final policy contained 28 directives. Enabling via Report-Only for 4 days revealed two hidden widgets. After deploying the strict policy, server load from blocks decreased by 92%.
What's Included in the Work
- Audit of the current site architecture and identification of all third-party resources (scripts, iframes, fonts).
- Development and configuration of CSP header (Report-Only and blocking modes).
- Documentation of the policy with explanation of each directive.
- Setup of an endpoint for report collection (via PHP or nginx).
- Training your developers: how to modify components to use nonce.
- Guarantee of stable operation: we fix incompatibilities within 5 working days after going live.
Timeline and Cost
Development and implementation of CSP with preliminary audit in Report-Only — from 4 to 8 hours depending on the number of third-party services. Audit starts from $500. You can save up to 90% on future CSP-related incidents. Contact us for a free estimate within 1 day. We have over 10 years of experience and 50+ security projects. Order an audit of your current policy today and get an engineer consultation.
Source: Wikipedia: Content Security Policy