Основи безпеки застосунків

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

Матеріал цієї глави стосується вебзастосунків і серверних компонентів у загальному вигляді. Конкретні налаштування залежать від фреймворку, сховища, способу входу, клієнтської платформи та середовища розгортання. Організація Open Worldwide Application Security Project (OWASP) публікує Application Security Verification Standard (ASVS) — відкритий стандарт вимог до технічної безпеки вебзастосунків. На дату перевірки стабільною версією ASVS була 5.0.0. Це карта контрольних вимог, а не обіцянка, що будь-який продукт із відміченими пунктами захищений від усіх загроз. (OWASP ASVS 5.0.0)

54.1. Почніть із загрози та меж довіри

Загроза — це ситуація, за якої хтось або щось може спричинити небажаний для продукту наслідок. Модель загроз — структурований опис того, що потрібно захистити, хто взаємодіє із системою, де проходять межі довіри, що може піти не так і які засоби зменшують ризик. OWASP описує моделювання загроз як повторюваний процес і радить починати з архітектури, потоків даних і меж довіри; універсального методу, однаково правильного для кожної команди, немає. (OWASP Threat Modeling Cheat Sheet)

Для першого проходу достатньо відповісти на шість запитань:

Питання	Приклад для кабінету постачальника
Який актив треба захистити?	Контракти, рахунки, контактні дані та право схвалити платіж.
Хто взаємодіє із системою?	Представник постачальника, працівник закупівель, адміністратор і зовнішній імпортер файлів.
Де точки входу?	Вебсторінки, програмний інтерфейс застосунку, завантаження документів, адреса зображення.
Де проходить межа довіри?	Між браузером і сервером; між запитом постачальника й даними інших постачальників; між застосунком і завантаженою адресою.
Що може піти не так?	Користувач прочитає чужий рахунок, документ виконуватиметься як активний вміст або імпортер звернеться до внутрішньої системи.
Який контроль і який залишковий ризик?	Перевірка доступу на сервері зменшує ризик читання чужих даних, але помилкова прив’язка самого рахунку до постачальника все ще потребує перевірки.

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

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

Власник продукту може попросити команду показати докази: де сервер перевіряє право на об’єкт; який тест підтверджує відмову для іншої організації; як повідомляють про вразливість бібліотеки й хто вирішує питання оновлення; як довго зберігається файл після видалення. Відповіді «є логін», «сканер зелений» або «ідентифікатори випадкові» самі по собі не доводять, що потрібний ризик контролюється.

54.2. Вхід до системи відповідає на інше запитання, ніж дозвіл

Автентифікація встановлює, хто звертається; авторизація перевіряє, чи може ця особа виконати конкретну дію з конкретним ресурсом. Успішний вхід не дає доступу до всіх рахунків: OWASP радить за замовчуванням відмовляти й перевіряти право на кожен запит. (OWASP Authorization Cheat Sheet)

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

У типовому вебзастосунку ідентифікатор сесії зберігається в cookie. Прапорець Secure обмежує її надсилання HTTPS-з’єднаннями, HttpOnly не дає сценаріям браузера прочитати значення, а SameSite обмежує надсилання в міжсайтових запитах. Поєднання прапорців залежить від способу входу й сумісності продукту.

Cookie — невелике значення, яке браузер надсилає разом із запитом. Для bearer-токена (токена-носія) так само важливо знати, де він зберігається, кому передається та як відкликається: строк життя й поведінка залежать від протоколу та застосунку.

Сервер має завершувати сесію після виходу, визначеного строку бездіяльності або абсолютного строку життя; точні строки залежать від чутливості даних і робочого процесу. Видалити cookie лише в браузері недостатньо, якщо сервер і далі приймає стару сесію. (OWASP Session Management Cheat Sheet)

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

Шифрування транспортного рівня (Transport Layer Security, TLS) захищає передавання даних між клієнтом і сервером, зокрема через HTTPS (Hypertext Transfer Protocol Secure, захищений протокол передавання гіпертексту). Воно допомагає зберегти конфіденційність і цілісність потоку та підтвердити клієнту, що він під’єднався до очікуваного сервера. Однак після завершення передавання дані опиняються в системі, де на них діють правила доступу, кешування, журналювання та зберігання. TLS не забороняє надмірний внутрішній доступ і не замінює авторизацію. (OWASP Transport Layer Security Cheat Sheet)

54.3. Перевіряйте право на кожен об’єкт на сервері

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

Повний розбір 1: чужий рахунок у кабінеті

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

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

Рішення. Сервер бере ідентифікатор організації з довіреного контексту сесії та включає його до перевірки запиту. Умовний псевдокод запиту:

SELECT invoice_number, total, due_date
FROM invoices
WHERE invoice_id = :invoice_id
  AND supplier_id = :current_supplier_id;

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

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

Значення invoice_id і current_supplier_id драйвер передає як окремі параметри; синтаксис прив’язування залежить від драйвера, але застосунок не має будувати SQL-конкатенацією тексту. Та сама перевірка має охоплювати не лише читання, а й редагування та завантаження документа.

Чому це краще. Рішення перевіряє саме правило «цей користувач може прочитати цей рахунок» незалежно від кнопок і складності номера. Негативний тест має підтвердити, що інший постачальник не прочитає, не змінить і не завантажить документ. Випадковий номер може зменшити випадкове вгадування, але він не є дозволом.

Межа та альтернатива. Перевірка в запиті бази даних проста для прямого зв’язку «рахунок — постачальник», але складна політика може вимагати централізованого сервісу авторизації або явних відносин спільного доступу. В обох випадках сервер має ухвалити рішення для кожної дії, а команда — показати, що критичні шляхи ним керуються. (OWASP Insecure Direct Object Reference Prevention Cheat Sheet)

54.4. Відокремлюйте дані від команд і коду

Валідація введення перевіряє, чи відповідає значення очікуваному домену: наприклад, дата існує, кількість невід’ємна, а формат і розмір файлу прийнятні. Вона корисна, але не є універсальним способом зробити текст безпечним у всіх місцях. Одне й те саме значення може потрапити в базу даних, сторінку мовою гіпертекстової розмітки (HyperText Markup Language, HTML), адресу запиту або журнал, де діють різні правила.

Вставлення команд у запит до бази даних

Мова структурованих запитів (Structured Query Language, SQL) описує команди до реляційної бази даних. SQL-ін’єкція виникає, коли застосунок збирає команду конкатенацією тексту так, що вхід користувача може стати частиною самої команди. Надійний типовий захист — запит із параметрами: структура команди задається окремо, а значення передаються через механізм зв’язування параметрів драйвера або фреймворку. Просте екранування всього введення — крихка заміна цьому розділенню. (OWASP SQL Injection Prevention Cheat Sheet)

Параметризація значень не завжди дозволяє підставити назву колонки чи напрям сортування. Такі фрагменти структури мають обиратися з обмеженого переліку, заданого застосунком; не збирайте їх із довільного рядка користувача. А перевірка права на запис лишається окремим шаром: захищений від SQL-ін’єкції запит усе ще може прочитати чужий рахунок, якщо в ньому немає умови власника.

Відображення даних у браузері

Міжсайтове виконання сценаріїв (Cross-Site Scripting, XSS) — клас вад, за яких браузер інтерпретує недовірені дані як активний вміст сторінки. Захист спирається на контекстно-залежне кодування виведення: дані стають текстом, а не кодом, за правилами місця вставлення. Звичайний текст, атрибут, адреса посилання й код сценарію потребують різного поводження. Віддавайте перевагу автоматичному екрануванню шаблонізатора й безпечним текстовим інтерфейсам браузера; уникайте вставляння довільної розмітки через «небезпечні» функції.

Якщо продукт підтримує форматований вміст, дозвольте вузький набір елементів та атрибутів і застосовуйте перевірений засіб очищення саме для цього контексту. Універсального засобу немає. Політика безпеки вмісту (Content Security Policy, CSP) може стати додатковим бар’єром, але сама не виправляє небезпечний спосіб виведення. (OWASP XSS Prevention Cheat Sheet)

Запити, які браузер надсилає автоматично

Міжсайтова підробка запиту (Cross-Site Request Forgery, CSRF) використовує те, що браузер може автоматично додати cookie до запиту на сайт, де користувач уже ввійшов. Якщо сайт покладається лише на цю сесію, стороння сторінка може спробувати змусити браузер виконати небажану дію від імені користувача.

Захист залежить від способу автентифікації й клієнта: використовуйте вбудований механізм фреймворку або перевірений CSRF-токен; за потреби перевіряйте джерело запиту й обмежуйте cookie атрибутом SameSite. Ці заходи потрібні для кожного запиту, що змінює стан; читальні запити не мають змінювати дані. XSS і CSRF — різні вади: XSS може обійти багато CSRF-захистів, тож усувати треба обидві. (OWASP CSRF Prevention Cheat Sheet)

54.5. Обмежуйте мережеву довіру сервера

Підробка запиту з боку сервера (Server-Side Request Forgery, SSRF) виникає, коли користувач впливає на адресу, до якої сервер виконує мережевий запит, а сервер має доступ до ресурсів, недоступних цьому користувачеві напряму. Приклади функцій із таким шляхом: імпорт зображення за посиланням, створення вебхука або отримання даних з інтеграції. Адреса ресурсу (Uniform Resource Locator, URL) може вказувати на зовнішній сайт, внутрішній сервіс або інший протокол; важливо, що запит робить сервер. OWASP рекомендує починати з вузького переліку довірених адрес, коли продукту не потрібно звертатися до будь-якого сайту. (OWASP SSRF Prevention Cheat Sheet)

Повний розбір 2: імпорт зображення з URL

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

Рішення та дія. Спершу з’ясуйте, чи потрібне серверне завантаження взагалі: можливо, користувач може завантажити файл у браузері або вибрати партнерський домен. Якщо імпорт із довільного URL необхідний, дозвольте очікувані схеми й перевіряйте адресу та кожну IP-адресу, на яку вона перетворюється, безпосередньо перед з’єднанням. Налаштуйте клієнт або контрольований проксі так, щоб він під’єднувався саме до перевіреної IP-адреси, а не шукав ім’я повторно. Перевіряйте кожну нову адресу після перенаправлення або вимкніть його. Система доменних імен (Domain Name System, DNS) може з часом повертати іншу адресу, тож одноразової перевірки імені недостатньо. Якщо зафіксувати перевірену IP-адресу неможливо, вихідний мережевий фільтр має контролювати фактичний напрямок з’єднання.

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

Спостережуваний результат. Зображення з дозволеного джерела проходить обмеження, зберігається як недовірений файл і показується лише після перевірки типу та розміру. Внутрішній чи недопустимий адресат відхиляється, надмірно великий або повільний файл не займає необмежений ресурс. Окремий журнал фіксує причину відмови без повного URL, якщо той може містити приватні параметри.

Чому це краще. Багаторівневі обмеження зменшують ризик, навіть якщо прикладна перевірка пропустить помилку.

Межа та альтернатива. Перелік доменів не підходить сервісу, який має імпортувати з будь-якого публічного сайту. Тоді парсер перевірки має однаково трактувати адресу з реальним мережевим клієнтом, а низькопривілейований сервіс — мати обмежений вихід у мережу. Прикладна перевірка не усуває помилку в бібліотеці чи новий спосіб обходу.

У травні 2026 року GitHub Advisory Database описала SSRF у Open WebUI (CVE-2026-45400): версії до 0.9.4 включно були уразливі, а 0.9.5 містить виправлення. Валідатор URL і мережева бібліотека трактували спеціальні символи по-різному, тому зовнішня на вигляд адреса могла спрямувати запит до внутрішньої цілі. PR #24534 і нотатки випуску підтверджують відхилення таких символів. Джерела підтверджують повідомлення й виправлення, але не експлуатацію в реальній інсталяції; цей патч також не доводить, що усунуто всі шляхи SSRF. (GitHub Security Advisory GHSA-8w7q-q5jp-jvgx; PR #24534; Open WebUI v0.9.5 release notes)

54.6. Керуйте залежностями та ресурсами

Застосунок успадковує ризики фреймворків, бібліотек, сторонніх скриптів і налаштувань інфраструктури. Інвентар залежностей і сканери допомагають знайти проблему, але треба перевірити, чи є компонент у розгорнутій збірці, чи досяжна вразлива функція, яке виправлення доступне й що змінить оновлення. Застаріла або невикористана бібліотека теж може виконуватися непрямо чи бути під’єднаною пізніше. Для стороннього скрипту в браузері з’ясуйте, який код запускається від імені сторінки, чи потрібен цей постачальник і як перевіряються його оновлення. (OWASP Vulnerable Dependency Management Cheat Sheet)

Повний розбір 3: виправлення бібліотеки з несумісною зміною

Ситуація. Інструмент сканування повідомляє, що бібліотека попереднього перегляду документів має відому вразливість; постачальник випустив виправлену версію. Уявімо, що новий випуск водночас змінює структуру результату, яку споживає імпортер. Це навчальна узагальнена ситуація, а не звіт про конкретний інцидент.

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

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

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

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

Обмежуйте споживання ресурсів

Ресурси також мають межі. Запит може бути автентифікованим і дозволеним, але створювати надмірну кількість обчислень, завантажень, задач черги або витрат на зовнішній сервіс. Обмежуйте розміри запитів і файлів, час виконання, кількість паралельних задач та частоту дорогих операцій. Ліміти мають виходити з вимірювань продукту й моделі загроз: єдиного значення запитів за хвилину для всіх систем немає. Перевірте і побічний ефект захисту: жорстке блокування входу може дозволити комусь заблокувати саму жертву. (OWASP Denial of Service Cheat Sheet)

54.7. Мінімізуйте дані й захищайте журнали

Безпека й приватність залежать від того, скільки даних продукт збирає, хто може їх прочитати, як довго вони зберігаються й чи справді видаляються з активних систем та резервних копій за визначеною політикою. Збирайте лише потрібні дані, обмежуйте доступ за роллю і завданням, установлюйте строки зберігання та пояснюйте шлях видалення. Дані на дисках і в резервних копіях можуть потребувати шифрування під час зберігання та окремого контролю доступу до ключів; саме шифрування не замінює авторизацію на рівні застосунку. (OWASP User Privacy Protection Cheat Sheet). Законодавчі обов’язки залежать від країни, типу даних і контексту; поле з галочкою не доводить відповідність конкретному правовому режиму.

Технічний журнал допомагає розібрати відмову, підозрілу дію чи помилку випуску, але не має ставати сховищем секретів і зайвих персональних даних. Зберігайте потрібний для розслідування контекст, обмежуйте доступ і строк зберігання. Клієнтові показуйте безпечне пояснення без стека викликів, SQL-запиту чи службового шляху. (OWASP Logging Cheat Sheet; OWASP User Privacy Protection Cheat Sheet)

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

54.8. Перевіряйте твердження, а не наявність інструмента

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

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

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

План реагування на підтверджену ваду має називати відповідального й наступну дію: обмежити або вимкнути вразливий шлях, повідомити потрібну команду, зберегти достатні для розслідування записи, розгорнути виправлення й перевірити відновлення функції. Порядок залежить від впливу та бізнес-контексту; відкликання доступу чи відкат коду не скасовує дані, які вже могли бути розкриті. Національний інститут стандартів і технологій США (National Institute of Standards and Technology, NIST) у публікації серії Special Publication (SP, спеціальна публікація) 800-61, редакція 3 (2025), розглядає реагування в ширшому циклі керування кіберризиком. (NIST SP 800-61 Rev. 3)

Питайте команду про перевірний доказ, відповідального й межу покриття, а не назву модної технології: який тест відхиляє чужий рахунок, до яких адрес не дістанеться імпортер і коли переглянуть тимчасове вимкнення вразливої функції?

Агентні запити мають проходити ті самі серверні перевірки доступу, що й інші клієнти. Наступна глава розглядає додаткові ризики недовіреного вмісту й інструментів агента.

Джерела та подальше читання

Усі вебджерела нижче перевірено 24 вересня 2026 року. Довідники OWASP Cheat Sheet Series є живими сторінками й не мають фіксованої версії; для повторного використання звіряйте їхній актуальний зміст. ASVS зазначено з номером версії, оскільки сам OWASP попереджає, що номери вимог можуть змінюватися.

1. OWASP Foundation, Application Security Verification Standard (ASVS), 5.0.0. Відкрита основа контрольованих вимог для проєктування та перевірки вебзастосунків. Сторінка проєкту.

2. OWASP Cheat Sheet Series, Threat Modeling Cheat Sheet. Описує активи, потоки даних, межі довіри та повторювані запитання для моделі загроз. Посилання.

3. OWASP Cheat Sheet Series, Authorization Cheat Sheet. Підтримує розмежування автентифікації та авторизації, відмову за замовчуванням і перевірку прав на кожен запит. Посилання.

4. OWASP Cheat Sheet Series, Insecure Direct Object Reference Prevention Cheat Sheet. Рекомендації щодо захисту доступу до конкретних об’єктів. Посилання.

5. OWASP Cheat Sheet Series, Session Management Cheat Sheet. Атрибути cookie, завершення та відкликання сесій. Посилання.

6. OWASP Cheat Sheet Series, Transport Layer Security Cheat Sheet. Межі захисту передавання, HTTPS, cookie та кешування чутливих відповідей. Посилання.

7. OWASP Cheat Sheet Series, SQL Injection Prevention Cheat Sheet. Відокремлення коду запиту від даних і параметризовані значення. Посилання.

8. OWASP Cheat Sheet Series, Cross Site Scripting Prevention Cheat Sheet. Контекстне кодування виведення, безпечні інтерфейси виведення та роль додаткових засобів. Посилання.

9. OWASP Cheat Sheet Series, Cross-Site Request Forgery Prevention Cheat Sheet. Захист запитів зі станом залежно від способу автентифікації та браузера. Посилання.

10. OWASP Cheat Sheet Series, Server-Side Request Forgery Prevention Cheat Sheet. Межі безпечного отримання зовнішніх ресурсів і захист на рівні застосунку та мережі. Посилання.

11. GitHub Advisory Database, GitHub Security Advisory (GHSA) GHSA-8w7q-q5jp-jvgx / CVE-2026-45400. Звіт опубліковано в репозиторії Open WebUI 10 травня, а запис у GitHub Advisory Database — 14 травня 2026 року. Межі версій і опис розбіжності модулів розбору адреси в Open WebUI. Посилання.

12. Open WebUI, Pull Request #24534, травень 2026 року. Первинне підтвердження зміни URL-перевірки для конкретного класу розбіжностей. Посилання.

13. Open WebUI, Release v0.9.5, травень 2026 року. Нотатки до випуску підтверджують включення виправлення. Посилання.

14. OWASP Cheat Sheet Series, Vulnerable Dependency Management Cheat Sheet. Облік, оцінювання, планування виправлення та робота з ризиком залежності. Посилання.

15. OWASP Cheat Sheet Series, Denial of Service Cheat Sheet. Ресурсні межі, розміри запитів і обмеження частоти як частина доступності. Посилання.

16. OWASP Cheat Sheet Series, Logging Cheat Sheet і User Privacy Protection Cheat Sheet. Безпечне журналювання та обмеження даних. Журналювання; приватність.

17. National Institute of Standards and Technology, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, квітень 2025 року. Базове джерело для включення реагування до процесу керування ризиком. Посилання.