Bitrix Security: Vulnerability Audit & Hardening

A single security incident — redirects to phishing or performance degradation — can cost a business over $1,000 per day of downtime. We know this firsthand: over 10 years, we've conducted 500+ Bitrix project audits. In every second one we found critical vulnerabilities: from XSS to SQL injection, from privilege escalation to fully open admin panels with default passwords. Vulnerability elimination is not a one-time action but a systematic process. We don't just patch holes; we implement a comprehensive set of measures: hardening, integrity monitoring, proactive filtering. This reduces reinfection risk by 90%. The cost of this approach is a fraction of your turnover, and savings from a single incident cover all expenses. Our team uses modern tools: vulnerability scanners, fuzzing, manual code audit. This allows us to find even hidden problems. Website security is not an option but a necessity. Customer data leaks can lead to lawsuits and reputation loss. Implementing security measures pays off after one incident. Check your site today — don't wait until attackers find a breach. We offer the full cycle: from audit to hardening and post-incident analysis. Below — what we do, how, and what results we guarantee.

Typical Vulnerabilities on Bitrix Sites

According to our statistics, 70% of projects contain XSS vulnerabilities. Cross-site scripting occurs when data from $_GET/$_POST is output without escaping in custom components and templates. Example:

// Vulnerable: echo $_GET['search'];
// Correct: echo htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8');
// Or via Bitrix D7: echo \Bitrix\Main\Text\HtmlFilter::encode($_GET['search']);

Reflective XSS in the search page URL is a typical vector. Check all URL parameters that are output in the template.

SQL injections — found in 30% of projects. They are outdated when using D7 ORM but alive in legacy code with $DB->Query():

// Vulnerable: $DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $_POST['login'] . "'");
// Correct: $DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $DB->ForSql($_POST['login']) . "'");

PHP injection via file upload — missing extension validation when uploading through custom forms. A file shell.php.jpg can be renamed and executed.

IDOR (insecure direct object references) — requests like /order/?ID=12345 without checking order ownership. In standard Bitrix components this is handled; in custom ones often not.

How We Eliminate Infections

If the site is already infected — the sequence:

1. Isolation: switch to maintenance mode or block external access.
2. Search for malicious code:

find /var/www -name "*.php" -exec grep -l "base64_decode|eval|system|exec" {} \; 

3. Analyze modification dates: files changed after the last deployment date are suspects.
4. Compare with a clean distribution: download a clean Bitrix version and compare kernel files via diff -r.
5. Change all credentials: admin passwords, API keys, DB password, FTP access.
6. Update kernel and modules to latest versions.

The b_security_log table — check events up to the infection moment. Often you can see the IP from which the vulnerability was exploited.

What Full Hardening Includes

A set of measures that closes 90% of typical attack vectors. A day of downtime due to infection costs businesses large sums — lost sales and reputation damage.

Why Hardening Is Necessary

After hardening, the site meets OWASP Top 10 standards and requirements of 54-FZ. 90% of typical attacks are blocked automatically. Read more about attack types on Wikipedia: Cross-site scripting and SQL injection.

Practical Case: Redirects for Bots

A large e-commerce store, "Business Plus" editorial. Symptoms: periodic redirects to third-party sites, but only for search engine bots (User-Agent). Bitrix scanner — clean. Analysis of files by modification date revealed a modified /bitrix/modules/main/include/prolog.php — code with User-Agent check and redirect was injected. Additionally: a backdoor in /bitrix/components/bitrix/main.include/component.php. Entry vector — compromised hosting FTP password (unchanged for years, leaked through another service).

Fix: restore kernel files from a reference distribution, change all passwords, enable two-factor authentication for FTP and SSH, set up SFTP with key-based authentication instead of passwords.

Preventive Measures After Cleanup

• File integrity monitoring: set up inotifywait or use the Bitrix "Integrity Control" module. This is 10x faster than manual checks once a month.
• WAF: enable and configure proactive filter in blocking mode.
• Regular updates: subscribe to Bitrix security updates mailing list.
• Access restriction: FTP/SSH only from specific IPs, deploy via CI/CD without permanent FTP access.

Additionally, we recommend reviewing Bitrix security documentation.

Timelines

Timelines depend on infection degree, custom code volume, and availability of pre-infection backups.

Order a security audit of your Bitrix site — get a detailed report and vulnerability remediation plan. Contact us for consultation.