Bitrix security audit: where breaches emerge
Breaches in a portal almost never appear because of a single mistake — they are created by a set of small concessions accumulated over time in operation.
A Bitrix security audit begins with inventory: which modules are installed, whether they are updated, who has access to the administrative area and on what basis. Already at this step, a significant portion of problems is identified.
A separate area is permissions. An account with full access, granted "temporarily" and left forever, or an editor role that technically allows inserting components with executable code, is a typical path to unauthorized access.
Portal security testing is built on the principle of least privilege: each action is confirmed by a role, not by the convenience of a specific employee.
Next are code and service entry points. Password recovery pages, externally accessible backup scripts, and test directories left after customizations expose data without authorization.
The same goes for outdated modules: a vulnerability in a component is often publicly known, but the update is postponed because "everything works." That is how Bitrix site vulnerabilities accumulate — one by one, unnoticed.
The server layer completes the picture: web server and database versions, file and directory permissions, availability of administrative ports, log rotation, and backup policy.
Here we look not at an individual setting but at the combination: a weak parameter is harmless by itself, but together with excessive permissions it provides a ready attack scenario.
The result is a prioritized list: what to close immediately, what to do on a planned basis, and which check will confirm that the breach has actually been eliminated.
Code, server, and access rights checks: what removes risks
Portal code checks begin with custom components, event handlers, and agents — everything written on top of the 1C-Bitrix core.
Typical findings: input escaping is not done everywhere, permission checks before a modifying action occur after writing, and request data reaches a query without parameterization.
Core updates do not close such defects — this is a class of failures that lives in the project until manually fixed.
We view server settings as an extension of the application: file system permissions, write access to upload directories, error output mode, listing of service directories, availability of the administrative section from outside, logging, and backups.
Here failure is measured not by a breakdown but by recovery time: without logs and a fresh copy, recovery is measured in hours.
We analyze user access rights by the group matrix and inheritance. Terminated employees, external contractors, and service accounts often retain extra access — up to the administrative section and exports.
Excessive permission manifests not as an attack but as accidental deletion or a leak through internal access.
The result of the check is not "it became safer" but measurable metrics: how much incident response time decreased, which classes of failures have left the project, and what share of critical paths is covered by checks. Updates become predictable because custom code stops relying on internal core structures.
Check options: one-time, regular, post-incident
Check modes do not replace each other — they answer different questions.
A one-time check provides a security snapshot for a specific date, regular monitoring shows what has changed since last time, and emergency analysis is needed when the site is already compromised or behaving strangely.
The choice depends on what is known about the system today: a fresh project without history, a live site with constant content edits and module updates, or an incident that must be closed and not repeated.
| Option | When it fits | Limitations |
|---|---|---|
| One-time security check | Before launch, after a major release, when changing contractor or hosting provider | Provides a snapshot as of a date: what is found is closed once, and subsequent changes in access rights and templates remain unmonitored |
| Regular configuration monitoring | The site is live, modules and components are updated, the set of administrators changes | Requires a reference list of values and a process for reviewing discrepancies, otherwise reports turn into a stream that no one reads |
| Change monitoring | A critical service where response in the first hours matters, not next week | Requires configured notifications and an on-call person who acts on them; false positives quickly devalue the channel |
| Incident analysis | There is suspicion of a hack, a load spike, extraneous files, or redirects | This is not prevention: localization and recovery come first, vulnerability checks follow after stabilization |
In practice, modes are combined: a one-time check is taken as a baseline, then change monitoring is enabled, while incident analysis remains an emergency scenario with pre-described steps.
Workflow: from access collection to report
An audit is not a one-time scanner run but a sequence of steps with a reproducible result at each one. We agree on access in advance and compile the report so that findings can be closed point by point and rechecked.
- Agreeing on access and boundaries. Portal administrator account, access to the file system and web server configuration, a copy of the database and backups. On the production environment — read-only access and logs.
- Portal map. Sites, custom modules and templates, public forms, exchanges, scheduled tasks. Custom code is the main risk area, and it is visible only through such a map.
- Configuration check. User group rights, 1C-Bitrix proactive protection settings, password policy, file access, event logs, and their retention period.
- Code and server check. Form handlers and file uploads, analysis of custom modules, process permissions, web server configuration, services accessible from outside.
- Prioritized report. For each finding: location in code or configuration, exploitation scenario, criticality class, and the specific fix.
- Remediation plan. First what opens external access, then the rest. We or your team make the fixes — with a check after each iteration.
- Verification check. We repeat the same scenarios on the fixed configuration and record what is closed and what remains, with justification.
The report and plan remain with you: you can use them to carry out fixes on your own or return to us for a repeat check.
What remains with you: policies, maps, and integration security
An audit ends not with a report but with a set of working artifacts that the team lives by going forward. We hand over each item below with an owner and check frequency — a document without an owner dies a month after delivery.
- Access map: portal roles and groups, a table of "who sees and changes what", separate service accounts for exchange tasks instead of one administrative account.
- Portal security policy: password and session lifetime requirements, mandatory two-factor verification for administrative roles, the procedure for granting rights to a new employee and revoking them upon termination.
- Backup rules: what we copy (files, database, user data, exchange settings), how often, where the second copy is stored, how often restoration is tested, and how long deployment takes.
- Security of integrations with 1C: list of exchange points, a separate service user for each link, rights strictly up to the required catalogs and documents, logging of exchange on both sides.
- Update policy: maintenance window, mandatory testing on a portal copy, rollback criteria, and who makes the decision about it.
- List of external modules and connections: what is installed, why, who owns it, when it was last checked.
- Setup of event log and notifications: which actions we log, what goes to the responsible person, and where incident analysis begins.
Such a set allows transferring the portal to another team or passing an audit without hastily reconstructing the access picture from memory.
Case study: how a request leak on a portal was closed
The client came after a partner forwarded a screenshot with someone else's requests: client inquiries from one line of business were visible in another.
The 1C-Bitrix portal served several hundred employees and partner companies, and at the time of contact no one could say who exactly was exporting data from the forms.
What was found in three days of analysis
The action log did not record reading and exports — only login and record edits. The "manager" role technically gave access to all sections with requests, and the service integration account with full rights stored the access key directly in the configuration.
That is, the leak source could be any of three: excessive rights, a reused key, or manual export through the administrative panel.
What was done
We separated rights by sections and operation types: reading, export, and deletion became different permissions. The service account was limited to a list of allowed methods, and the key was moved to secure storage with rotation.
We enabled logging of reading, exports, and permission changes — with each operation tied to an account and address.
Metrics before and after: before — several thousand records per day went outside the policy, there were no traces in the log, and incident analysis ran into manual matching and took about two weeks.
After — zero unaccounted exports, all operations with requests are tied to a specific user, and a full incident analysis takes twenty minutes.
Access control was restored, but the main thing is that observability appeared: now a leak is visible at the attempt stage, not from a partner's complaint.
What to do if the site is already infected or there is a suspicion of a hack?
Signs of a hack rarely look unambiguous: a search engine adds a label, antivirus complains about a downloadable file, orders disappear from the admin panel, and load grows while traffic falls.
The first thing to do is not clean the code but record the state — take a copy of files and database onto separate media, save web server and admin login logs. If you erase the traces immediately, you will no longer be able to find the entry point.
Next, we isolate the infected site: switch it to a placeholder, close the admin panel by IP allowlist, disable script execution in upload directories, and stop scheduler tasks.
We do not turn off the server — logs and network connections show where data is going and which channel the attacker uses. At the same time, we change administrator passwords, access keys, and integration tokens, otherwise a repeat login will occur using stolen access.
We look for the entry point by file modification dates and traces in the configuration: edits in .htaccess, extraneous scripts in upload directories, extra entries in autostart and scheduler tasks, modified templates and components.
The entry point is often not a hole in the core but forgotten access — an account of a terminated employee, a test domain with a production database, a Bitrix module without updates. It is this channel that determines what will have to be redone so that the attack does not repeat.
We restore from a clean copy taken before the incident and check the archive itself for infection — otherwise the attack will return along with the restoration.
After deployment, we update the core and modules, rebuild the server configuration, and enable file integrity control and monitoring of suspicious activity.
We define the incident response plan in advance: who isolates, who has access to copies, and how many hours it takes to bring up the working version.
Common doubts: access, load, module updates
Most doubts before an audit are organizational: no one wants to open the production environment, stop the portal, and receive a list of a hundred items that no one has time to close. We answer the four questions asked most often.
The general principle is read first, touch later. Static analysis of code, configuration, and access rights is performed on a copy and file dumps: the production portal continues to operate as usual during this time.
Are administrator logins and server access required?
Required, but not full and not indefinite. We create a separate account with read rights to the configuration, logs, and list of installed modules; to check permission separation — access to the administrative part of the portal.
Credentials are transmitted over a secure channel, are valid only during the work, and are revoked after the report is delivered.
Will the check slow down the portal?
We run dynamic and load scenarios on a copy of the production environment: we reproduce traffic, limit the number of concurrent requests, and choose a window outside working hours.
On the portal itself, we only collect logs and metrics that do not compete for resources with users. If a copy cannot be stood up, the check narrows to the static part — the timeline increases, but service operation does not change.
What to do about missed module updates?
Updating everything in a row on production is the worst option: edits in modules are overwritten, and the portal breaks on the very first release.
The order is reverse: inventory of the core and modules, recording customizations, updating on a copy with key scenarios run, then transfer to production. The rollback point is a backup and server snapshot before the start.
How long does the check take?
A typical portal takes from three to five business days from the moment access is received. The timeline grows if there are many custom components, third-party developer modules, or core edits. We provide an exact estimate after reviewing the project structure.
Let's discuss the task: how the start of work is structured
Starting work does not require a hundred-page technical specification from you. It is enough to show the landscape: how many sites and portals run on 1C-Bitrix, where they are hosted, who on the client side is responsible for the server, and who approves changes. This is enough to estimate the scope of the check and give realistic timelines.
- List of resources and their purpose: storefront, personal account, internal portal, data exchange with the accounting system.
- Hosting scheme: one server or several, where the database is located, where static files are, whether there is a separate environment for edits.
- Entry points and roles: which user groups exist and what rights are granted to administrators.
- Read access: a site copy, web server settings, event logs. We do not touch the production portal during this.
- Responsible person on the client side: one person who makes decisions and confirms work windows.
The first stage is inventory and scope assessment. We assemble a map of components, modules, and third-party extensions, review permission settings and logs, and then provide a portal protection work plan with priorities: what we close immediately and what can be postponed. Each item has an owner and a deadline.
After the check, the portal does not remain unattended. Post-check support includes monitoring of settings changes, module updates, and re-checking after releases. Describe the task — we will come back with a scope estimate and a first-stage plan.