Як зламують сайти компаній і що виправити насамперед?

Як насправді зламують сайти компаній? Значно частіше через пропущене оновлення, пароль, украдений деінде, бекап у публічній папці чи скрипт, який ніхто не перевіряв, ніж через атаку, вигадану спеціально під одну компанію. Розбираємо шість звичних шляхів, список власника і список розробника, скільки годин займає робота і що робити в першу годину після зламу. Це матеріал для тих, хто захищається: тут написано, що закривати, і немає нічого про те, як ламати.

КОРОТКО

Як зламують сайти насправді

Більшість сайтів компаній зламують через звичайні діри: застарілі плагіни та фреймворки, вкрадені паролі адміністраторів, недбале завантаження файлів, файли й бекапи в публічних папках, сторонні скрипти та акаунти, які ніхто не закрив. Закривати їх варто в такому порядку: спершу доступи, далі бекапи й оновлення, потім відкриті файли та завантаження, потім скрипти. Для типового сайту це від 30 до 75 годин роботи за нашою оцінкою, а далі щомісячна рутина.

Звіт Verizon Data Breach Investigations Report 2026 охоплює понад 22 000 підтверджених витоків у 145 країнах за період із жовтня 2024 року до листопада 2025 року. Використання вразливості в програмах стало найчастішим способом проникнення: 31% витоків, проти 16% у фішингу і 13% у зловживання обліковими даними. У регіоні Європа, Близький Схід і Африка картина різкіша: 47% вразливості, 28% фішинг, 6% облікові дані, тож тут першими варто закривати оновлення й пошту. У малому та середньому бізнесі третя сторона брала участь у 55% витоків. Ці цифри описують усі види витоків, зокрема й сайти, тому читати їх варто як напрямок, а не як статистику про сайти.

Напрямок корисний: вразливість, яку починають масово використовувати за кілька годин після публікації, ні на кого конкретно не націлена. У списку опиняється кожен, у кого стоїть ця програма.

Щоб ваш сайт атакували, нікому не треба обирати саме вашу компанію.

ШІСТЬ ШЛЯХІВ

Шість шляхів і що їх закриває

Ці шість шляхів охоплюють більшу частину того, що ми перевіряємо, коли сайт приходить до нас:

OWASP Top 10 за 2025 рік дивиться на вебзастосунки з боку коду й підтверджує ту саму картину: на першому місці порушений контроль доступу, на другому помилки конфігурації, на третьому збої в ланцюгу постачання програм. Якусь форму перших двох OWASP знайшов у 100% перевірених застосунків. Контроль доступу часто проходить будь-яку візуальну перевірку: інтерфейс ховає кнопку, а сервер однаково виконає запит, якщо він надійде. Правило OWASP звучить як «за замовчуванням заборонено», і застосовується воно в серверному коді.

Жоден сканер не перевірить ці правила за вас, бо те, хто може бачити яке замовлення чи рахунок, і є вашою бізнес-логікою. Це ще один аргумент будувати систему навколо того, як компанія працює насправді, і записувати ролі раніше за екрани. QA і тестування потім перевіряє їх реальним акаунтом кожної ролі. Продукт, швидко зібраний за допомогою ШІ-інструментів, тут зазвичай найслабше місце. Наша оцінка MVP, від $3 000, каже, що залишити, доопрацювати чи переписати, а як ми це вирішуємо, розібрано в статті Ви зібрали MVP за допомогою ШІ. Залишити, доопрацювати чи переписати?

СТАРИЙ КОД

Оновлення й календарі підтримки

Найкраще цифрами описані плагіни. Patchstack нарахував в екосистемі WordPress за 2025 рік 11 334 нові вразливості, на 42% більше, ніж у 2024-му: 91% у плагінах, 9% у темах і лише 6 у ядрі WordPress. Зважена медіана часу до першого використання найпопулярніших у зловмисників вразливостей становила 5 годин, а для 46% вразливостей на момент розкриття в розробника не було виправлення. У тестах Patchstack традиційний захист хостингу заблокував 12% атак на WordPress через уже відомі вразливості. Patchstack сам продає захист від цього, тож останню цифру варто зважувати з поправкою. Сам WordPress тут виглядає добре; ризик залежить від того, скільки плагінів на сайті й хто їх ще підтримує. На OpenCart ми цих цифр не переносимо, але логіка та сама: модулі сторонніх авторів оновлюються кожен у своєму темпі.

Звідси два практичні висновки. Видалений непотрібний плагін закриває ризик, який оновлення може й не закрити, адже майже половина вразливостей з'являється без готового виправлення. OWASP радить те саме: прибирати залежності, якими не користуєтеся, і стежити за компонентами, які більше ніхто не підтримує. І до швидкості варто ставитися чесно: за даними Verizon, у 2025 році повністю виправили лише 26% вразливостей зі списку CISA, куди входять вразливості з підтвердженим використанням, а медіана зросла до 43 днів із 32 роком раніше. Набори даних різні, тому розрив між 43 днями і 5 годинами є ілюстрацією, а не виміром.

У замовних системах та сама робота будується навколо публічних календарів підтримки. Станом на листопад 2026 року:

Дати застаріють, звичка залишиться. Занесіть їх у календар на рік наперед, проводьте кожне оновлення на закритій копії й випускайте його в годину, коли клієнтів найменше. Наприкінці потрібна справжня тестова заявка, а не просто сторінка, що відкрилася. Порядок роботи описано в статті Оновлення старого сайту на Laravel чи PHP у 2026 році. Там є й сайт, власник якого не мав видимих причин хвилюватися: PHP 5.6 на сервері, хостинг-акаунт під контролем людини поза компанією, службові скрипти у відкритому доступі й помилки PHP, які могли показуватися відвідувачам. Контрольований переїзд вирішив це за два вечори.

Коли сайт відстав на кілька версій, ціна залежить більше від занедбаності, ніж від відстані між версіями; чому, пояснює стаття Прихований технічний борг, через який редизайн сайту коштує дорожче за план. Такий випадок починається з аудиту в межах послуги Модернізація сайту: оновлення PHP, Laravel і CMS, від $300 для невеликих сайтів і від $1 000 для великих.

ДОСТУПИ

Паролі та забуті акаунти

Найнаочніший публічний приклад ризику з паролями це кампанія 2024 року проти клієнтів Snowflake, хмарної платформи даних. Mandiant не знайшов ознак зламу самої Snowflake; повідомили близько 165 організацій, які могли постраждати. На акаунтах не було багатофакторної автентифікації, щонайменше у 79,7% облікові дані вже витікали раніше, а частину з них було вкрадено ще в листопаді 2020 року і відтоді не змінювали.

Актуальний посібник NIST, SP 800-63B-4, пішов далеко від правил, які багато компаній досі застосовують. Пароль, що використовується як єдиний фактор, має бути не коротшим за 15 символів. Вимоги до складу й примусову періодичну зміну скасовано, крім випадків, коли є ознаки компрометації, а нові паролі треба звіряти зі списками тих, що витекли. У документі прямо сказано, що паролі не захищають від фішингу, тому для найважливіших акаунтів кращим другим кроком буде апаратний ключ або passkey.

Вмикайте вхід у два кроки в такому порядку, бо кожен акаунт може скинути чи замінити наступний:

1. Реєстратор домену. Хто володіє доменом, той може спрямувати ваш сайт і пошту куди завгодно.
2. Основна робоча пошта. Сюди приходять скидання паролів від усього іншого.
3. Хостинг і доступ до сервера. Звідси видно код, базу й бекапи.
4. Репозиторій коду і деплой. Зміна тут потрапляє на робочий сайт.
5. Адмінка сайту, платіжні акаунти й менеджер тегів. Менеджер тегів може поставити скрипт на будь-яку сторінку, зокрема оплату.

Покинуті акаунти дають той самий ризик, лише з відстрочкою: компанія може мати сильні заходи захисту й водночас чинні доступи до сервера в колишніх підрядників, які ніхто не відкликав. Ведіть один перелік того, хто й куди може зайти і на кого оформлено кожен акаунт. Давайте людям найвужчу роль, з якою можна працювати, щоб контент-менеджер не керував користувачами. Співробітників, які йдуть, вимикайте, а не видаляйте, тоді історія дій лишиться читабельною. Розділ із заявками чи даними клієнтів можна закрити окремим другим логіном.

Паролі та API-ключі зберігайте у файлах оточення або сховищі секретів, поза кодом. Документація Laravel каже про це прямо: файл .env не має потрапляти в систему контролю версій. Якщо ключ там уже опинився, правильний перший крок описано в GitHub, і він підходить для будь-якого хостингу коду: відкликати чи змінити ключ і лише потім думати про чищення історії. Зміна підрядника означає зміну цих ключів того самого дня; про це стаття Як прийняти сайт або застосунок від іншого розробника: що забрати насамперед.

ФАЙЛИ Й ЗАВАНТАЖЕННЯ

Завантаження й забуті файли

Посібник OWASP із тестування описує, як працюють відкриті файли: перейменована чи резервна копія файлу зазвичай віддається як простий текст, а не виконується, і це розкриває серверний код і паролі. Дамп бази в публічній папці взагалі не потребує зламу. Тримайте копії для відкату, дампи й логи поза всім, що віддає вебсервер, і не правте файли просто на робочому сервері: редактори залишають тимчасові копії.

Просту перевірку можна зробити на своєму сайті, і лише на ньому. Запитайте ваш-сайт/.env і ваш-сайт/.git/config. Потрібна відповідь це 403 або 404. Відповідь 200 із вашою звичайною сторінкою «не знайдено» буде хибною тривогою, про такі OWASP попереджає окремо. Якщо відкрився сам файл, закрийте його негайно й вважайте кожен пароль усередині вкраденим. Заодно переконайтеся, що режим налагодження на робочому сайті вимкнено. Laravel попереджає, що з увімкненим APP_DEBUG ви ризикуєте показати відвідувачам чутливі значення конфігурації, а OWASP відносить докладні повідомлення про помилки до частих помилок налаштування.

Для завантаження файлів в OWASP короткий перелік:

• дозволяйте лише ті типи файлів, які потрібні бізнесу, за списком, а не забороняйте окремі;
• перевіряйте справжній тип файлу, бо тип, заявлений браузером, легко підробити;
• давайте кожному файлу нове ім'я, створене застосунком;
• зберігайте завантаження на окремому хості або поза коренем сайту, з мінімальними правами;
• обмежте розмір і дозвольте завантаження лише авторизованим користувачам.

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

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

СКРИПТИ

Скрипти, які писали не ви

Кожен тег на сайті працює з тими самими правами, що й ваш власний код. У звіті Verizon 2026 року третя сторона бере участь у 48% усіх витоків, на 60% більше, ніж роком раніше, а в роздрібній торгівлі у 68%.

Кожен скрипт на сторінці оплати може прочитати те, що вводить покупець.

Два випадки показують, як це виглядає для власника сайту. У лютому 2024 року новий власник купив домен і акаунт GitHub популярної JavaScript-бібліотеки Polyfill. У червні Sansec повідомив про шкідливий код, упроваджений на понад 100 000 сайтів, які її завантажували. Код спрацьовував лише на певних мобільних пристроях у певні години й оминав адміністраторів, тож власник, відкриваючи сайт із робочого комп'ютера, нічого не помічав. Раніше, у справі British Airways 2018 року, трафік перенаправлявся на підроблений сайт, було викрадено платіжні дані приблизно 429 612 клієнтів і співробітників, а злам лишався непоміченим понад два місяці. Британський регулятор оштрафував компанію на £20 млн і назвав багатофакторну автентифікацію для співробітників і сторонніх акаунтів серед заходів, які могли допомогти.

Для всіх, хто приймає картки, з 31 березня 2025 року це формальна вимога. Вимога 6.4.3 стандарту PCI DSS каже, що кожен скрипт на платіжній сторінці має бути дозволений, його цілісність підтверджена, а всі скрипти занесені до реєстру з письмовим обґрунтуванням. Вимога 11.6.1 додає механізм, який попереджає співробітників про несанкціоновані зміни сторінки й HTTP-заголовків у тому вигляді, в якому їх отримує браузер.

Багато магазинів вбудовують форму платіжного провайдера в iframe і вважають, що їх це більше не стосується. PCI SSC справді прибрав обидві вимоги з анкети SAQ A, але додав умову: продавець підтверджує, що його сайт не вразливий до атак через скрипти. Підтвердити це можна способами на кшталт описаних у 6.4.3 та 11.6.1 або письмовим підтвердженням від провайдера, що відповідає стандарту. Як саме це оформити, запитайте у свого еквайра, адже сам PCI SSC виконання стандарту не контролює.

З картками чи без, робота та сама: перелічити всі скрипти, зокрема додані через менеджер тегів, прибрати те, що ніхто не може пояснити, і тримати платіжні сторінки майже порожніми. Subresource Integrity дає змогу браузеру відмовитися від зовнішнього файлу, вміст якого більше не збігається з хешем; це працює для фіксованих версій бібліотек. Content Security Policy вказує браузеру, які скрипти можна завантажувати, і почати можна з режиму report-only, щоб нічого не зламати, поки ви з'ясовуєте, чим сторінки користуються насправді.

ДВА ПЕРЕЛІКИ

Перелік власника й перелік розробника

Більшу частину ризику власник може знайти, не читаючи код. Поставте ці питання своїй команді чи підряднику; за нашою оцінкою, на збір відповідей піде приблизно пів дня:

• Чи оформлено домен, хостинг і основну пошту на компанію, і чи можете ви зайти в них сьогодні?
• Чи ввімкнено для кожного з них вхід у два кроки?
• Хто зараз може зайти на робочий сервер, поіменно, і коли цей перелік перевіряли востаннє?
• Які версії PHP, фреймворку чи CMS працюють на сайті й коли закінчується їхня підтримка безпеки?
• Коли бекап востаннє відновлювали, скільки це зайняло і чого забракло? Тест описано в статті Неперевірені бекапи й рахунки за хмару, що ростуть: два ризики робочої системи.
• Які скрипти працюють на сторінці оплати й у формах заявок, і хто їх затвердив?
• Хто відповідає за інцидент, який час реакції записано в договорі, хто ваш юрист і контакт у платіжного провайдера?

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

Разом від 30 до 74 годин. Порядок важливіший за суму: доступи й бекапи йдуть першими, бо обмежують шкоду від усього, що поки лишається відкритим.

ПЕРША ГОДИНА

Перша година після зламу

Ця послідовність зберігає вам можливості; юридичною консультацією вона не є. Її основу взято з посібника американської FTC для бізнесу, і логіка там не залежить від країни.

1. Призначте одного відповідального й почніть письмовий журнал із часом. Хто що помітив і коли. Залучіть розробника, потім юриста, а якщо могли постраждати дані клієнтів чи карток, то й фахівця з розслідування.
2. Нічого не стирайте й поки не відновлюйте. FTC прямо пише «не знищуйте докази» і радить відключити уражене обладнання від мережі, але не вимикати машини до приходу експертів. Попросіть хостинг зберегти логи сервера, бо логи перезаписуються.
3. Обмежте шкоду. Переведіть сайт чи уражену частину в режим обслуговування. Якщо сторінка оплати може красти дані карток, спершу вимкніть платежі.
4. Змініть доступи з чистого пристрою. Хостинг, база, адмінка, пошта, платіжні та API-ключі, плюс завершіть усі активні сесії. Як зазначає FTC, украдені логіни працюють і після видалення інструментів зловмисника.
5. Знайдіть точку входу, перш ніж повертати сайт. Чистий бекап, відновлений поверх відкритої діри, можуть заразити знову, тому виправлення йде разом із відновленням.
6. Уточніть обов'язки з юристом. Які обов'язки повідомляти діють для вас за Законом України «Про захист персональних даних», перевірте в актуальній редакції: строків ми тут не наводимо, бо не змогли звірити їх із чинним текстом. Якщо ви продаєте людям в ЄС, стаття 33 GDPR дає 72 години на повідомлення регулятора, де це можливо, а GDPR може поширюватися на компанії без офісу в ЄС. Якщо зачеплено картки, телефонуйте платіжному провайдеру.

Коли сайт чистий, відкрийте звіт «Проблеми безпеки» у Google Search Console: зламані сторінки можуть отримати попередження в пошуку й у браузерах. Виправте всі перелічені проблеми на всіх уражених сторінках, потім надішліть запит на перевірку й опишіть, що зробили. За словами Google, перевірка при шкідливому коді займає кілька днів, а при зламі зі спамом може зайняти до кількох тижнів.

ХТО ЦЕ РОБИТЬ

Хто тримає це закритим

Зробити це один раз не вийде: з'являються нові вразливості, люди йдуть, маркетинг додає теги. Наша послуга Підтримка та обслуговування сайтів закриває цю рутину: оновлення фреймворку, PHP і пакетів, патчі безпеки, щоденні бекапи поза сервером із тестами відновлення, моніторинг і щомісячний звіт, від $1 000 на місяць, час реакції зафіксовано у вашому плані. Доступи, секрети, сервери й конвеєри релізів це робота інженерів послуги DevOps і хмарна інфраструктура, від $50 до $70 на годину, а перевірка ролей перед великими релізами належить до QA, від $30 на годину. Якщо людей, які робили сайт, уже немає, почніть з аудиту перед прийомом проєкту, від $2 500. Усі ціни зібрані на сторінці цін.

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

Доступ, який можна перелічити, можна й закрити.

FAQ

Джерела

• Verizon: 2026 Data Breach Investigations Report, executive summary
• OWASP Top 10:2025
• Patchstack: State of WordPress Security in 2026
• Mandiant, Google Cloud: UNC5537 targets Snowflake customer instances
• Sansec: Polyfill supply chain attack