API та запити
Атаки, які зловживають формою запиту або довірою, яку браузер надає твоєму сайту. Їх легко пропустити, бо звичайний клієнт їх ніколи не надсилає.
Чек-лист
- Захищай запити, що змінюють стан, від CSRF. Якщо ти автентифікуєш через cookie, кожна кінцева точка, яка змінює стан, потребує CSRF-токена або суворої політики SameSite для cookie. Якщо ти автентифікуєш через bearer-токен у заголовку Authorization (а не через cookie, що надсилається автоматично), класичний CSRF не застосовується, і це одна з причин віддавати перевагу такому підходу.
- Закрий login-CSRF. Навіть потік входу можна підробити: прив'яжи OAuth
stateдо браузера через cookie, встановлений на початку, і перевірений під час callback. Див. автентифікацію. - Обмеж CORS. Ніколи не віддзеркалюй довільний
Originі ніколи не використовуйAccess-Control-Allow-Origin: *разом з обліковими даними. Став явний список дозволених джерел і лише потрібні методи та заголовки. Стандартне "дозволити все" - поширена помилка каркасу. - Заборони mass assignment. Не передавай тіло запиту безпосередньо в оновлення
бази даних. Приймай явний список полів, доступних для запису, щоб користувач не
міг надіслати
{"role":"admin"}або{"plan":"enterprise"}і підвищити свої права. Позначай поля лише для читання та ігноруй невідомі. - Надавай привілеї та платний стан лише з довіреної події. Тариф або баланс кредитів має змінюватися з перевіреного вебхука платежу або дії адміністратора, ніколи зі значення в запиті користувача.
- Перевіряй вебхуки. Перевір підпис провайдера над сирим тілом, переконайся, що сума і валюта збігаються з очікуваними, і зроби кожну подію ідемпотентною, щоб повтор не застосувався двічі.
- Перевіряй типи вмісту та розміри. Відхиляй неочікувані типи вмісту і обмежуй розмір тіла до розбору.
Як тестувати
- Додай
role,is_admin,planабоcreditsдо запиту на оновлення і переконайся, що сервер їх ігнорує. - Надішли міжсайтовий запит і переконайся, що CORS не віддзеркалює твоє джерело.
- Повтори вебхук двічі і переконайся, що він застосувався один раз.