Skip to content
rxt.sh
Русский

Sample report

What an audit report looks like

The system is invented: the domain, addresses and numbers are made up. The findings are typical for a 1C-Bitrix online shop on two servers. A real report has the same structure and stays with you even if you go no further.

Request the audit

Sample · invented system

Site
shop.example.com
Stack
1C-Bitrix, PHP 8.1, MySQL 8
Servers
2 dedicated, CDN in front
Audit took
5 working days

In short

Three findings can cost money today: the customer database downloads from a direct link, the server answers around the CDN, and backups sit on the same disk and have never been restored. The catalogue answers in 2.8 seconds under load, and almost all of that is server settings, not code. The fix is $1800 and two weeks; the first two findings are closed on the day it is signed.

01

Findings — ordered by what they could cost

  1. 01 · Critical

    A database dump is downloadable from the internet

    What we saw
    /backup/db_2026-10-01.sql.gz, 1.4 GB, sits in the web root and is served without authentication.
    What it risks
    A leak of the customer base: phone numbers, addresses, order history — and the regulatory exposure that comes with it.
    Fix
    Config change: remove the file, refuse archives and dumps at the nginx level.
    Effort
    An hour, on the day of signing
    Check it yourself · 01
    $ curl -sI https://shop.example.com/backup/db_2026-10-01.sql.gz
HTTP/2 200
content-length: 1503238553

  2. 02 · Critical

    The server answers around the CDN

    What we saw
    The backend address is found through a stale DNS record, mail.shop.example.com, and it accepts site requests directly.
    What it risks
    The CDN's DDoS protection and filtering do nothing: an attacker only needs the address.
    Fix
    Config change: allow 443 from CDN addresses only, drop the record, move mail to its own address.
    Effort
    Half a day
    Check it yourself · 02
    $ curl -sI --resolve shop.example.com:443:203.0.113.20 \
    https://shop.example.com/
HTTP/2 200

  3. 03 · Critical

    Backups on the same disk, never restored

    What we saw
    A nightly script writes a site and database archive to /var/backups on the same server. The last 3 copies are kept.
    What it risks
    A disk failure, ransomware or an admin mistake takes the site and every copy at once.
    Fix
    Rebuild: restic to S3 at a different provider, encrypted, 30 days retention, a monthly restore drill.
    Effort
    Two days

  4. 04 · Important

    Catalogue: p95 of 2.8 seconds under load

    What we saw
    At 20 requests per second the catalogue p95 TTFB is 2.8 s. The 128 MB OPcache is full and keeps resetting; three catalogue components have caching off; the filter query takes 1.2 s without an index.
    What it risks
    A slow catalogue means fewer orders and worse search rankings. During a sale the site hits its ceiling before the ads do.
    Fix
    Config change: 512 MB OPcache, component caching, an index for the filter. Target: p95 under 600 ms at the same load.
    Effort
    Three days, measured before and after
    Check it yourself · 04
    $ php -r "print_r(opcache_get_status()['memory_usage']);"
[used_memory] => 134217728
[free_memory] => 0

  5. 05 · Important

    PHP-FPM: 5 workers on a 16 GB server

    What we saw
    pm.max_children = 5, the default. Under load requests queue while memory sits at 30%.
    What it risks
    The site is slow with resources to spare: the sixth concurrent shopper waits.
    Fix
    Config change: a pool sized to the real per-process memory, and the PHP slow log on.
    Effort
    Part of the catalogue work

  6. 06 · Important

    The admin panel is open to the whole internet

    What we saw
    /bitrix/admin/ is reachable from anywhere, two-factor login is off, and the log shows password guessing.
    What it risks
    One guessed manager password is full access to the shop and its database.
    Fix
    Config change: admin reachable only from the private network or an address list, 2FA, brute-force blocking.
    Effort
    Half a day

  7. 07 · Important

    Two modules with published vulnerabilities

    What we saw
    The core and two third-party modules have not been updated in over a year; both modules have public vulnerability write-ups.
    What it risks
    The standard way shops get broken into: a known hole in a module nobody updates.
    Fix
    Update on staging, check ordering and payment, roll out in a window. Where no update exists — a WAF rule on the vulnerable path.
    Effort
    Two days

  8. 08 · Important

    Order emails land in spam

    What we saw
    SPF exceeds the 10 DNS lookup limit, there is no DKIM signature, and no DMARC record.
    What it risks
    The customer never sees the order confirmation and writes to support — or does not come back.
    Fix
    Config change: SPF within the limit, DKIM, DMARC with reports; transactional mail from its own domain.
    Effort
    A day

  9. 09 · Fine

    TLS and certificates

    What we saw
    TLS 1.2 and 1.3, modern cipher suites, certificates renew automatically.
    What it risks
    None.
    Fix
    Leave as is.
    Effort
    —

02

The server bill

The second server runs at 15% and only hosts cron jobs. They can move to the first, and the second can be replaced by a smaller machine for a database replica — roughly 40% off that line of the bill. This is a recommendation, not part of the fix: your call.

03

Price and timeline for the fix

Config changes (findings 1, 2, 4, 5, 6, 8)
$1050
Backup rebuild (3)
$400
Module updates (7)
$350
Total, fixed
$1800
Timeline
Two weeks

The price is named in the report and does not move during the work. You can take part of the list — then only the chosen lines count.

Your report will be about your system: different findings, a different order, a different number. The form is this one.

Request the auditAbout the audit