Словник безпеки API: автентифікація, авторизація і не тільки

Обговорення безпеки API наповнені скороченнями і поняттями, які легко заплутати — автентифікація проти авторизації, потоки OAuth, структура JWT. Якщо ви переглядаєте проект безпеки, пишете модель загрози або пояснюєте вразливість колегі, точний словник запобігає дорогим нерозумінням. У цьому повідомленні описано терміни, з якими ви найчастіше стикаєтеся у справжній роботі з безпекою API.

---

Профіль: автентифікація проти авторизації

** Автентифікація ** (часто скорочується до * AuthN *) — Перевірка * того, хто * викликає. Фраза: “API автентифікує виклики за допомогою API-ключів — кожен ключ пов’язаний з конкретною клієнтською програмою.”

** Авторизація ** (часто скорочується до * AuthZ *) — Визначення * того, що * автентифікований викликаючий має право робити. Фраза: “Автентифікація пройшла, але авторизація зазнала невдачі — користувач не має обсягу admin, необхідного для доступу до цієї кінцевої точки.”

Часта помилка: * « API повернув 401 Неавторизований » * — але 401 насправді означає * неавтентифікований * (недійсні улікові дані). * 403 Заборонено * означає * неавторизований * (дійсні улікові дані, недостатні права доступу). Це розрізнення має значення в звітах про інциденти і переглядах дизайну API.

---

OAuth 2.0 і PKCE

** OAuth 2. 0 ** — це система авторизації, яка надає стороннім програмам змогу отримати обмежений доступ до ресурсу від імені користувача. OAuth визначає декілька * потоків * (також званих * типами надання *) для різних випадків використання.

** Потоки OAuth 2. 0 ** — головні потоки:

• • Код авторизації * — для веб- програм на стороні сервера; найбільш безпечний
• • Код авторизації + PKCE * — для публічних клієнтів (SPA, мобільні програми), де секрет клієнта не може зберігатися конфіденційним
• • Клієнтські дані * — для автентифікації між машинами (M2M); без участі користувача
• • Авторизація пристрою * — для пристроїв з обмеженими можливостями вводу (телевізори з підтримкою технології Smart TV, засоби CLI)

Фраза: “Ми використовуємо поток Client Credentials для конвеєра даних — це служба backend без контексту користувача.”

** PKCE (Proof Key for Code Exchange) ** (вимова: * « pixie » *) — розширення потоку авторизаційного коду, яке захищає від атак перехоплення за допомогою * перевірки коду * і * виклику коду *. Потрібно для публічних клієнтів. Фраза: “Мобільне застосування використовує PKCE — воно генерує код перевірки локально і відсилає тільки гешований виклик на сервер авторизації.”

---

Знаки і підписи

**JWT (JSON Web Token) ** (вимова: “jot”) — компактний, самостійний формат токенів. JWT має три частини, закодовані в Base64URL, відокремлені крапками: header, payload і signature. Фраза: “Декодувати JWT вантаж на jwt.io для перевірки тверджень — але ніколи не довіряти вантажу без перевірки підпису.”

Claims — Пари ключ-значення в JWT, що описують предмет, видання, термін дії і нетипові дані (наприклад, sub, iss, exp, scope ). Фраза: “The JWT has a custom claim tenant_id — the API uses it to route requests to the correct database shard.”

** HMAC (код автентифікації повідомлення на основі гешування) ** — симетричний алгоритм підписування, який використовується для підписування JWT (HS256) або перевірки корисного навантаження webhook. Обидві сторони мають один і той же секретний ключ. Фраза: “Webhook payloads are signed with HMAC-SHA256 — verify the signature before processing.”

** Ключ API ** — простий секретний рядок, переданий у заголовку запиту або параметрі запиту для розпізнавання клієнта API. Простіше, ніж OAuth, але надає менше деталізації. Фраза: “Негайно поверніть ключ API — він був випадково переданий до публічного сховища.”

** mTLS (Mutual TLS) ** — Обидва клієнти і сервери надають сертифікати для автентифікації один одного. Поширений в обміні даними між службами в мережі служб. Фраза: “mTLS застосовується між внутрішніми службами — жодна служба не може викликати іншу без чинного сертифіката клієнта.”

---

Захист і захист

** CORS (Cross- Origin Resource Sharing) ** — Механізм безпеки переглядача, який обмежує, з яких джерел можна надсилати крос- джерельні запити. Неправильно налаштований CORS (наприклад, Access-Control-Allow-Origin: * на автентифікованому API) є поширеною вразливістю. Фраза: “Політика CORS дозволяє лише запити з нашого виробничого домену — походження шаблонів ніколи не дозволяється на автентифікованих кінцевих точках.”

** CSRF (Cross- Site Request Forgery) ** — атака, яка обманює переглядач користувача, щоб він зробив автентифікований запит до вашого API. Зменшено за допомогою CSRF-токенів, куки SameSite і перевірки заголовка Origin.

** Захист від введення ** — перевірка і очищення всіх вхідних даних API для запобігання введення SQL, введення команд та подібних атак. Фраза: “Використовувати параметризовані запити — ніколи не інтерполювати введення користувача безпосередньо в SQL.”

** Обмеження швидкості ** — обмеження кількості запитів на клієнта за часовий проміжок, щоб запобігти зловживанню і атакам з використанням жорстокої сили.

** Безпека шлюзу API ** — Централізація автентифікації, авторизації, обмеження швидкості і перевірки вводу на рівні шлюзу, а не у кожній службі.

OWASP API Security Top 10 — Широко цитований список найкритичніших ризиків безпеки API, включаючи Пошкоджена авторизація рівня об’єкта (BOLA), Пошкоджена автентифікація, Занадто велика експозиція даних і Масове призначення. Фраза: “Контрольний список перегляду безпеки заснований на OWASP API Security Top 10 — BOLA є найпоширенішим виявленням.”

---

** Практика: ** Прочитайте OWASP API Security Top 10 (owasp. org/ www- project- api- security/) і напишіть одноречення з визначення кожного ризику вашими словами. Потім порівняйте з колегою - відмінності виявляють прогалини в розумінні.

Навигація нуансів: практичний підхід до розмов про безпеку

Будьмо чесними - обговорення безпеки API може відчуватися… технічним. І коли ви намагаєтеся пояснити складні поняття, такі як авторизація або автентифікація, легко втратитись у жаргоні. Одним з найбільших викликів для носіїв англійської мови, які не є її рідними носієм, є не тільки розуміння * того, що * сказано, але також * як * це сказано - тонкі нюанси, що впливають на ясність і ефективність. Розглянемо, як ці поняття часто обговорюються у професійному середовищі, особливо коли йдеться про потенційні проблеми або про запити на зміни.

Наприклад, уявіть, що ви переглядаєте запит на звантаження нової кінцевої точки розпізнавання користувача. Розробник реалізував JWT (JSON Web Tokens), але не визначив явно обсяг прав, наданих кожному з токенів. Корисний коментар, який ви можете залишити, не буде просто « JWT потребує обсягу ». Замість цього ви можете сказати: « Ця реалізація хороша, але давайте роз’ яснюємо обсяги, пов’ язані з цими JWT. Нам потрібно переконатися, що користувачі мають доступ тільки до тих ресурсів, які вони * насправді * потребують - підхід «найменших привілеїв». Чи можемо ми додати коментарі до коду, де буде детально описано, для яких кінцевих точок API буде авторизовано кожен JWT? Це значно допоможе вам зрозуміти і перевірити майбутні зміни. » Аналогічно, у каналах Slack, присвячених розробці API, ви можете почути, як хтось каже: « Сервер відповідає з помилкою 403 Заборонено — здається, що авторизація зазнала невдачі. Нам потрібно перевірити, чи є реєстраційні дані користувача чинними * і* чи вони мають правильні права для цієї конкретної дії. ” Це стосується точності і чіткого опису проблеми з точки зору контролю доступу.

Інший поширений сценарій включає в себе опис запитів на зміни. Замість того, щоб просто сказати « оновити CORS », ви б сформулювали це так: « Нам потрібно вдосконалити налаштування CORS, щоб строго обмежити, які домени можуть отримувати доступ до нашого API. На даний момент будь-який домен може робити запити — це становить значний ризик. Ми повинні реалізувати підхід білого списку, дозволяючи лише запити з відомих і надійних джерел. ” Цей рівень деталізації є критичним під час спілкування з зацікавленими сторонами, які, можливо, не мають глибокого розуміння основних механізмів безпеки.

Крім того, важливо пам’ятати, що документація не просто перелік визначення; це про надання контексту. Добре написана специфікація API чітко сформулює * чому * були прийняті певні рішення щодо автентифікації і авторизації - наприклад, пояснює, чому PKCE (Proof Key for Code Exchange) було обрано над іншими методами для потоку входу в мобільне застосування.

Ось приклад того, як ви можете використовувати curl для перевірки доступу після налаштування CORS:

curl -H "Origin: https://example.com" https://api.example.org/users

Ця команда показує перевірку налаштованого правила CORS — переконання, що запити, що надходять з https://example.com, буде дозволено, а інші можуть бути заблоковані. Знання цих практичних прикладів допоможе вам впевнено обговорювати питання безпеки і ефективно робити свій внесок у проекти розробки API.