OWASP Top 10:2025 для веброзробників: що змінилося і як захищатися

OWASP Top 10 — найближче до спільної мови, що є у веббезпеці. На нього посилаються аудитори, про нього питають клієнти в анкетах безпеки, і саме з нього розробники починають вивчати тему. Редакція 2025 року, опублікована наприкінці 2025-го, — перше оновлення з 2021 року, і вона відображає зміщення атак: від помилок у нашому власному коді до того, як ПЗ збирається, конфігурується й складається із залежностей. У гайді проходимо перелік, пояснюємо зміни і даємо конкретні заходи захисту для типових застосунків на Next.js, Node.js і Java.

Перелік одним поглядом

Місце	Категорія	Зміни порівняно з 2021
A01	Broken Access Control	Досі №1; тепер включає server-side request forgery (SSRF)
A02	Security Misconfiguration	Піднялася з №5
A03	Software Supply Chain Failures	Нова, розширена з «Vulnerable and Outdated Components»
A04	Cryptographic Failures	Опустилася з №2
A05	Injection	Опустилася з №3
A06	Insecure Design	Опустилася з №4
A07	Authentication Failures	Те саме місце, нова назва
A08	Software or Data Integrity Failures	Те саме місце
A09	Security Logging and Alerting Failures	Те саме місце, тепер наголос на алертах
A10	Mishandling of Exceptional Conditions	Нова категорія

Рейтинг побудовано на даних про понад 2,8 млн протестованих застосунків від 13 організацій, зіставлених із 589 CWE; дві категорії додано за результатами опитування спільноти, щоб охопити ризики, які автоматичне тестування ще погано покриває (OWASP Top 10:2025).

A01: Broken Access Control

Дії користувачів поза межами їхніх прав залишаються найпоширенішою серйозною вразливістю: перегляд чужого замовлення зміною ID в URL, виклик адмінських API зі звичайного акаунта чи змушування сервера звертатися до внутрішніх URL (SSRF, тепер частина цієї категорії).

Захист:

Забороняйте за замовчуванням і перевіряйте авторизацію на сервері для кожного запиту на рівні ресурсу, а не лише «чи залогінений».
Ніколи не довіряйте ID від клієнта. Шукайте записи в межах поточного користувача чи тенанта.
Проти SSRF перевіряйте і обмежуйте білим списком хости призначення для будь-яких серверних запитів, блокуйте доступ до внутрішніх і метаданих IP-діапазонів.

// Route handler у Next.js: запит обмежено автентифікованим користувачем
export async function GET(_req: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  const session = await auth()
  if (!session) return new Response("Unauthorized", { status: 401 })
  const order = await db.order.findFirst({ where: { id, customerId: session.user.id } })
  if (!order) return new Response("Not found", { status: 404 })   // не розкриваємо існування
  return Response.json(order)
}

Server Actions у Next.js — теж публічні HTTP-ендпоінти; перевіряйте авторизацію всередині кожного, як в API-маршруті.

A02: Security Misconfiguration

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

Захист: інфраструктура як код із переглянутими дефолтами, заголовки безпеки (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options), окремі конфігурації для середовищ і автоматичне сканування конфігурації в CI. Наш шаблон пайплайна — у статті CI/CD без болю.

A03: Software Supply Chain Failures

Нова категорія охоплює все між вашим кодом і продакшеном: залежності, системи збірки, CI-пайплайни, контейнерні образи й реєстри пакетів. Хрестоматійний приклад — компрометація популярного GitHub Action tj-actions/changed-files у березні 2025 року, що розкрила секрети тисяч репозиторіїв (CISA, 2025).

Захист:

Lock-файли, перевірка залежностей у pull request'ах і автоматичні оновлення з тестами.
Пінінг CI-екшенів і базових образів до digest; мінімальні права CI-токенів.
Генерація SBOM, підпис артефактів і перевірка підписів перед деплоєм.

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

A04: Cryptographic Failures

Чутливі дані передаються чи зберігаються без належного захисту: звичайний HTTP, слабке хешування паролів, саморобне шифрування, ключі у вихідному коді. Використовуйте TLS скрізь, сучасну функцію хешування паролів на кшталт Argon2id чи bcrypt, перевірені криптобібліотеки платформи і менеджер секретів замість env-файлів у Git.

A05: Injection

SQL, NoSQL, OS command, LDAP і template injection, а також XSS. ORM і параметризовані запити розв'язують більшість SQL-ін'єкцій; кодування виводу і строга Content Security Policy обмежують XSS. Обережно з raw-запитами і з dangerouslySetInnerHTML у React: санітизуйте HTML від користувачів чи з Markdown перед рендерингом.

У застосунках з LLM-функціями відповідь моделі — теж недовірений ввід. Ставтеся до неї як до користувацького вводу перед рендерингом чи виконанням — пояснюємо у статті Безпека AI-агентів.

A06: Insecure Design

Вади, яких не виправить жоден правильний код: відновлення пароля, що розкриває існування акаунта, бізнес-логіка, яка дозволяє від'ємну кількість у кошику, відсутні ліміти на дорогі операції. Захист — моделювання загроз на етапі дизайну, сценарії зловживань поруч із user stories і безпечні патерни проєктування.

A07: Authentication Failures

Credential stuffing, слабкі парольні політики, зламана робота із сесіями, відсутня багатофакторна автентифікація. Використовуйте перевіреного провайдера ідентичності чи фреймворк, підтримуйте passkeys чи MFA, обмежуйте спроби входу, змінюйте ідентифікатор сесії після входу і анулюйте його при виході.

A08: Software or Data Integrity Failures

Довіра до коду чи даних без перевірки цілісності: автооновлення без підписів, десеріалізація недовірених даних, CI-пайплайни, що приймають неперевірені зміни. Перевіряйте підписи, уникайте небезпечної десеріалізації (класика Java-екосистеми) і захищайте пайплайни захистом гілок та обов'язковими рев'ю.

A09: Security Logging and Alerting Failures

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

A10: Mishandling of Exceptional Conditions

Друга нова категорія — про те, що відбувається, коли щось іде не так: обробка помилок, що «відкриває двері» (fail open), необроблені винятки, що залишають транзакції наполовину застосованими, stack traces, які розкривають внутрішню будову, чи стани гонки під навантаженням.

// Fail closed: помилка в перевірці прав має забороняти, а не дозволяти
boolean canAccess;
try {
    canAccess = permissionService.check(user, resource);
} catch (Exception e) {
    log.error("Permission check failed for user={} resource={}", user.id(), resource.id(), e);
    canAccess = false;
}
if (!canAccess) throw new AccessDeniedException("Forbidden");

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

Як перетворити перелік на практику

Зіставте загрози з десятьма категоріями для кожного застосунку і пріоритезуйте за рівнем доступності ззовні.
Автоматизуйте те, що можна: сканування залежностей, SAST, пошук секретів, перевірки конфігурації і DAST у CI.
Переглядайте вручну те, що не можна: вади контролю доступу й дизайну потребують людського рев'ю і тестів.
Навчайте розробників категоріям, найбільш релевантним для вашого стеку.
Використовуйте OWASP ASVS, коли потрібен детальний перевірюваний чек-лист, а не документ для обізнаності (OWASP ASVS).

Чек-лист безпеки для code review

Додайте ці запитання в шаблон pull request'а — вони ловлять значну частину проблем із Top 10 до релізу:

Чи кожен новий ендпоінт чи Server Action перевіряє авторизацію на рівні ресурсу, а не лише автентифікацію?
Чи використовується користувацький ввід у запиті, команді, шаблоні чи HTML без параметризації чи кодування?
Чи обробники помилок «закривають двері» (fail closed) і не повертають клієнту внутрішніх деталей?
Чи нові залежності справді потрібні, підтримуються і зафіксовані за версією?
Чи секрети не потрапляють у код, логи і клієнтські бандли?
Чи логуються події, важливі для безпеки, з достатнім контекстом?

FAQ

Чи є OWASP Top 10 стандартом відповідності? Ні. Це документ для підвищення обізнаності. Для перевірюваних вимог використовуйте OWASP Application Security Verification Standard (ASVS).

Чому injection опустився на №5? Фреймворки, ORM і безпечні налаштування за замовчуванням зробили його менш поширеним у протестованих застосунках. Коли він трапляється, наслідки досі серйозні.

Чи охоплює перелік специфічні для LLM ризики? Ні. OWASP веде окремий Top 10 для LLM-застосунків, що охоплює prompt injection і пов'язані ризики.

Як часто оновлюється перелік? Приблизно раз на три-чотири роки; попередня редакція — 2021 року.

Джерела

OWASP. OWASP Top 10:2025 і Introduction.
OWASP. Application Security Verification Standard (ASVS).
CISA (2025). Supply chain compromise of tj-actions/changed-files (CVE-2025-30066).
OWASP GenAI Security Project. OWASP Top 10 for LLM Applications.