Про безпеку сайту власники бізнесу згадують двічі: коли підрядник виставляє рахунок за підтримку — і коли Google починає показувати відвідувачам червоний екран «Цей сайт може завдати шкоди вашому компʼютеру». Між цими двома моментами зазвичай минає рік-два тиші, у якій «і так усе працює».
Проблема в тому, що безпека — це не окрема кнопка й не антивірус, який можна поставити наприкінці. Це кілька дуже базових звичок, які або є, або їх немає. Розберемо чесно: чому ламають саме малий бізнес, чим це реально закінчується, звідки беруться дірки — і що робити, якщо вже сталось.
Головний міф: «кому ми потрібні, ми маленькі»
Це найдорожча помилка в темі, тому почнемо з неї.
Ніхто не сидить і не обирає ваш сайт особисто. Зломи давно масові й автоматичні: програми-сканери цілодобово перебирають інтернет підряд і перевіряють усе, що трапляється, на вже відомі публічні дірки — ті, для яких виправлення вийшло пів року тому, але на вашому сайті так і не встановилось.
Для такого сканера сайт-візитівка стоматології, лендінг автосервісу й великий магазин виглядають абсолютно однаково — як рядок в списку. Бізнес потрапляє не тому, що він цікавий, а тому що він дірявий. «Ми маленькі» не є захистом, бо ніхто не питав про ваш розмір.
І ламають не заради ваших даних. Найчастіше зламаний сайт — це просто безкоштовний ресурс: з нього зручно розсилати спам, роздавати шкідливі файли, розміщувати чужі посилання або тихо перенаправляти ваших відвідувачів кудись іще.
Чим це закінчується для бізнесу
Тут важливо розуміти: технічна шкода — не найгірше. Найгірше — наслідки для продажів.
- Google позначає сайт як небезпечний. Замість вашої сторінки людина бачить попередження червоним екраном. Трафік обнуляється практично миттєво.
- Виліт із видачі. Сайт зі шкідливим кодом або спам-сторінками може взагалі зникнути з результатів пошуку — а повертатись туди потім довго й нервово (про сам механізм зникнення ми писали в матеріалі чому сайту немає в Google).
- Хостинг блокує сайт. Якщо з вашого акаунта пішов спам — провайдер просто вимкне його, не питаючи. Сайт лежить, поки ви розбираєтесь.
- Редирект відвідувачів. Людина клікає вашу рекламу — і потрапляє на чужий сайт. Ви платите за клік, гроші йде комусь іншому.
- Витік даних клієнтів. Заявки, телефони, контакти з форм. Це вже репутація й питання до вас.
- Вимога викупу. Сайт шифрують або блокують і пропонують «домовитись».
- Тижні відновлення. Без бекапу зламаний сайт — це часто не ремонт, а розробка наново.
Найдорожче тут — не робота програміста. Найдорожче — місяці, за які позиції в пошуку просіли, а клієнти не могли до вас достукатись.
Звідки насправді беруться дірки
Хороша новина: причин небагато й вони до нудного передбачувані.
- Застаріла CMS, тема й плагіни. Це причина номер один із великим відривом. Виправлення виходять регулярно, але поки їх ніхто не встановив — сайт залишається відкритим для того, що вже давно всім відомо. «Не чіпай, воно працює» — саме той підхід, який ламає сайти.
- Слабкі й повторно використані паролі. Один і той самий пароль на хостингу, пошті й адмінці означає, що витік в одному місці відкриває все одразу. Плюс відсутність двофакторної автентифікації.
- Доступи, які забули забрати. У колишнього підрядника, у звільненого контент-менеджера, у стажера, який рік тому щось правив. Ці облікові записи ніхто не контролює, а працюють вони так само, як ваш.
- Плагіни й теми з сумнівних джерел. Платна тема, знайдена «безкоштовно», — класика: усередині часто йде подарунок, який ви не замовляли.
- Забагато зайвого. Десяток плагінів, з яких реально працюють два. Кожен зайвий — це ще один шматок чужого коду, який теж може мати дірку.
- Відсутність бекапів. Це не причина злому — але саме через це злом перетворюється на катастрофу.
Помітили спільне? Це не хакери — це відсутність регулярного обслуговування. Саме тому оновлення й бекапи входять у підтримку сайту: не як спосіб взяти з вас гроші, а тому що це і є єдиний реальний захист.
Що зробити, щоб не втратити сайт
Мінімальний список, який закриває більшість ризиків. Без нього все інше не має сенсу.
- Оновлення — це регулярна робота, а не реакція на поломку. Раз на місяць хтось має заходити й оновлювати CMS, теми, плагіни. Не «коли зламається».
- Менеджер паролів + двофакторна автентифікація на все. На хостинг, на домен (реєстратора), на адмінку сайту, на пошту. Пошта — критична: через відновлення пароля з неї відкривається решта.
- Ревізія доступів. Просто відкрийте список користувачів з правами адміністратора й чесно скажіть, хто з них потрібен сьогодні. Решту — прибрати. Робити це варто щоразу, коли міняється підрядник чи співробітник.
- HTTPS. Базова гігієна, сьогодні це має бути за замовчуванням.
- Бекапи, які лежать ОКРЕМО від сайту. Бекап на тому ж сервері, що й сайт, — це не бекап: його зламають разом із сайтом. І головне: бекап, який ніколи не відновлювали, — це не бекап, а надія. Перевірте його хоч раз.
- Менше зайвого коду. Чого немає — те не ламають. Приберіть плагіни, які не використовуються.
- Моніторинг доступності. Щоб про проблему ви дізнавались від сервісу, а не від клієнта в дірект через три дні.
- Захист форм від спаму. Інакше форма зворотного звʼязку перетворюється на канал розсилки.
Частина цього залежить від провайдера — наскільки стабільний хостинг і чи робить він бекапи автоматично. Це один із критеріїв, який ми розбирали в матеріалі як вибрати хостинг для сайту.
Архітектура вирішує більше, ніж плагіни
Тепер важлива думка, яку зазвичай не кажуть: найнадійніший захист — це не додати щось, а не мати чого ламати.
Статичний сайт — це набір готових файлів. У нього немає адмінки, немає бази даних, немає коду, який виконується на сервері під час візиту відвідувача. А отже, немає й найчастішого сценарію: підібрати пароль до адмінки або знайти дірку в старому плагіні. Сканеру там просто нема за що зачепитись.
Для лендінга, сайту-візитівки чи сайту послуг це принципово інший рівень ризику — і сильний аргумент на користь такої технології, а не тільки питання швидкості. Ми детально порівнювали підходи в матеріалі WordPress чи Next.js: CMS дає зручне редагування ціною постійного обслуговування, статика знімає більшість цих турбот.
Це не абсолютний захист — домен, хостинг-акаунт і пошта все одно потребують сильних паролів і 2FA. Але площа для атаки зменшується в рази.
Сюди ж — власність. Домен і хостинг-акаунт мають бути оформлені на вас, а не «десь у підрядника». Інакше в критичний момент ви навіть не зможете нічого зробити зі своїм сайтом. Про це — у матеріалі як вибрати підрядника для сайту.
Якщо вже зламали: алгоритм дій
Коротко й по порядку. Головне — не робити двох типових помилок: не панікувати й не «просто почистити».
- Зупиніть шкоду. Закрийте сайт для відвідувачів (технічне обслуговування) або попросіть хостера тимчасово вимкнути його. Поки сайт роздає шкідливе — накопичуються санкції.
- Змініть усі паролі. Хостинг, домен, адмінка, пошта, бази, FTP. Усі. І перевірте список адміністраторів — там може зʼявитись «зайвий».
- Відкотіться на чистий бекап. Саме відкат на копію, зроблену завідомо до інциденту, а не ручне вичищення файлів. Вичищаючи, майже завжди щось пропускають.
- Закрийте саму причину. Це найважливіший пункт, який пропускають найчастіше. Якщо ви відновили сайт, але не оновили те, через що зайшли, — повернуться за кілька днів. Оновити все, прибрати зайве, забрати чужі доступи.
- Перевірте Google Search Console. Там є звіт із питань безпеки. Після усунення проблеми подайте запит на повторну перевірку — інакше попередження висітиме, навіть коли сайт уже чистий.
- Попередьте клієнтів, якщо витекли дані. Неприємно, але чесно — і дешевше за наслідки мовчання.
Якщо бекапу немає й відкочуватись нема куди — це вже не відновлення, а фактично збірка сайту наново. Часто це нагода зробити нормально: на сучасній технології, з нормальними доступами (див. редизайн сайту), а перенести вміст без втрати позицій — окреме завдання, яке ми розбирали в матеріалі про переїзд сайту.
Головне
Ламають не вибірково, а масово й автоматично: боти перевіряють усе підряд на вже відомі дірки, і «ми маленькі» від цього не рятує. Найчастіша причина — застаріла CMS і плагіни, які ніхто не оновлює, плюс слабкі паролі й забуті доступи. Наслідки бʼють не по серверу, а по продажах: попередження Google, виліт із видачі, заблокований хостинг, тижні відновлення. Захист — це нудні базові речі: регулярні оновлення, 2FA всюди, ревізія доступів, менше зайвого коду й бекапи, які лежать окремо і які ви реально перевіряли. А якщо зламали — відкат на чистий бекап і обовʼязково закрити саму дірку, інакше повернуться.
Ми в Obliko робимо сайти так, щоб їх було нічим ламати: статична архітектура без адмінки й бази, доступи оформлені на клієнта, бекапи окремо від сайту. А якщо сайт уже зламали — допоможемо відновитись і закрити причину, а не просто прибрати наслідки. Напишіть, що у вас за сайт і що сталось, — підкажемо, з чого починати.
Кому потрібен мій маленький сайт? Навіщо його ламати?
Це найпоширеніший і найдорожчий міф. Ваш сайт ніхто не обирав особисто — його знайшли автоматично. Боти цілодобово сканують інтернет підряд і перевіряють усе, що трапиться, на вже відомі публічні дірки в старих версіях CMS і плагінів. Бізнес потрапляє не тому, що він цікавий чи багатий, а тому що він дірявий: сайт-візитівка перукарні й великий магазин для сканера виглядають однаково. Далі зламаний сайт використовують як безкоштовний ресурс — розсилати спам, роздавати віруси, розміщувати чужі посилання чи перенаправляти ваших відвідувачів на сторонні сторінки.
Що найчастіше стає причиною злому сайту?
У переважній більшості випадків — не якась хитра атака, а звичайна занедбаність. Найчастіша причина: застаріла CMS, тема чи плагіни, які роками ніхто не оновлював, хоча виправлення давно вийшло. Далі йдуть слабкі або повторно використані паролі й відсутність двофакторної автентифікації. Окрема поширена історія — доступи, що залишились у колишнього підрядника чи звільненого співробітника, та плагіни й теми, завантажені з сумнівних джерел «безкоштовно». Бекапи не є причиною злому, але їх відсутність перетворює неприємність на катастрофу.
Що робити, якщо сайт уже зламали?
Не панікувати й не намагатись «просто почистити» — по-перше, закрийте сайт для відвідувачів або зверніться до хостера, щоб зупинити шкоду. Далі змініть усі паролі (хостинг, домен, адмінка, пошта, FTP/бази) і перевірте список користувачів з правами адміністратора. Потім відкотіться на завідомо чистий бекап, зроблений до інциденту, а не вичищайте файли вручну — так надійніше. Обовʼязково закрийте саму причину (оновіть усе, приберіть зайве), інакше повернуться за кілька днів. Наприкінці перевірте звіт безпеки в Google Search Console й попросіть повторну перевірку, а якщо витекли дані клієнтів — попередьте їх.
Чи можна зробити сайт, який майже нічим ламати?
Можна суттєво зменшити площу для атаки самою архітектурою. Статичний сайт — це набір готових файлів без адмінки, без бази даних і без коду, який виконується на сервері під час візиту. Класичного «зайти в адмінку й підмінити файли» там просто немає, а разом із ним зникає й найчастіший сценарій масових автоматичних зломів. Це не абсолютний захист (домен, хостинг-акаунт і пошта все одно потребують сильних паролів і 2FA), але це принципово інший рівень ризику для сайту-візитівки чи лендінга.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.