Чи це надмірна інженерія, якщо я додаю захист від навмисних помилок користувача (м'яко кажучи), якщо шкода, яку може завдати користувач, не пов’язана з моїм кодом?
Для уточнення я відкриваю просту послугу JSON RESTful на зразок цього:
GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item
Сама послуга призначена не для використання через веб-переглядач, а лише з сторонніх програм, керованих користувачем (наприклад, телефонними програмами, настільними програмами тощо). Крім того, сама послуга повинна бути без громадянства (тобто без сеансу).
Аутентифікація проводиться за допомогою базової автентифікації через SSL.
Я говорю про таке можливе "шкідливе" поведінку, як це:
Користувач вводить URL-адресу GET у веб-переглядачі (без причини, але ...). Браузер запитує Basic Auth, обробляє його та зберігає auth для поточного сеансу перегляду. Не закриваючи браузер, користувач відвідує шкідливий веб-сайт, на якому є шкідливий CSRF / XSRF javascript, який робить POST нашим сервісом.
Наведений вище сценарій малоймовірний, і я знаю, що з точки зору бізнесу я не повинен надто хвилюватися. Але заради покращення ситуації, чи вважаєте ви, що, якщо в даних JSON POST також будуть введені ім’я користувача / пароль, допоможе?
Або я повинен взагалі скинути Basic Auth, позбутися GET і використовувати лише POST / PUT з інформацією про авторизацію в них? Оскільки інформація, отримана через GET, також може бути чутливою.
З іншого боку, чи вважає використання користувацьких заголовків чистою реалізацією REST? Я можу скинути Basic Auth та використовувати власні заголовки. Таким чином можна уникнути принаймні CSRF-атаки з браузера, і програми, які використовують сервіс, встановлять ім'я користувача / пароль у користувальницькому вересі. Погано для цього підходу полягає в тому, що зараз сервіс не можна споживати з браузера.