Коротко: Да! Должен!
Я уже не один раз слышал от фронтендеров, что за безопасность должен думать бэкенд разработчик и пускай там делают защиту от XSS. Да, на бэкенде можно снизить риски (к примеру, настроить CSP было бы правильно), но корневая причина находится именно на фронте. И это ответственность фронтендера думать про защиту от XSS.
Кстати, с валидацией данных, мы имеем зеркальную ситуацию: фронтенд может делать валидацию, но бэкенд обязан. 🙂
Почему фронтендер?
⭕ Причина 1️⃣: XSS - это проблема процесса рендеринга данных.
Одни и те же данные можно использовать по разному в разных ситуациях и разных клиентах (браузер, консоль, мобильное приложение). И мы должны рендерить данные безопасно. Сегодня они могут прийти с надежного бэкенда, а завтра с какого-то внешнего, к примеру. Нет причины, чтобы использовать небезопасный рендеринг на клиенте (возможно за редким исключением).
Если этой причины мало, то переходим к следующей 🙂.
⭕ Причина 2️⃣: бэкендер не следит за изменениями фронтенда.
Бэкенд-разработчик на заморачивается у вас там просто textarea на фронте или WYSIWYG-редактор.
Давайте проведем мысленный эксперимент. У нас есть REST API endpoint, который возвращает информацию про пользователя и там два поля: "name" и "bio". Эти два поля отображаются обычным текстом в интерфейсе. И тут приходит продакт-менеджер и говорит, давай дадим пользователям возможность форматировать текст в bio. Ты подключаешь какой-то редактор и в этот момент твое приложение становится уязвимым к XSS, если ты про это не подумаешь.
Почему так произойдет?
❓ Есть ли гарантия того, что бэкендер знает, что нужно сделать изменения на бэке, если задача была чисто фронтовая?
❓ Есть ли гарантия того, что ваш продакт-менеджер поставит бэкендеру задачу про XSS вместе с фронтовой задачей для тебя?
❓ Если ты не знаешь про XSS, то как ты поставишь задачу бэкендеру?
❓ Если ты не знаешь про XSS, то как ты добавишь защиту на фронте?
В итоге бэкендер не в курсе, продакт не занимается этими вопросами, а фронтендер считаешь, что это не его ответственность. То есть, даже с процессной стороны возникает проблема.
Если этих двух причин мало, то переходим к следующей 🙂.
⭕ Причина 3️⃣: бэкенд должен знать про верстку фронта, чтобы сделать правильную защиту.
Стандартный механизм защиты это использования санитайзера (внешния библиотека типа DOMPurify) Никогда не используйте регулярки для защиты от XSS❗.
Но это настолько стандартная для фронтенда задача, что сейчас утверждается браузерный API (https://wicg.github.io/sanitizer-api/). Только это уже говорит о том, что этим должны пользоваться фронтендеры.
Но проблема еще более интересная. Если вы посмотрите на API, то вы заметите, что санитайзер должен знать в какой элемент рендерится html разметка, поскольку это влияет на алгоритм парсинга.
Цитирую: "If the user data is available in string form and the developer wishes to sanitize it now, but apply the result to the DOM later, then the Sanitizer must be informed about the context that it will be used."
Примеры:
sanitizer.sanitizeFor("div", htmlMarkup);
sanitizer.sanitizeFor("table", htmlMarkup);
То есть бэкенд не просто должен знать, что вы будете использовать строку как html, но и должен знать как у вас сверстана страница.
Общий вывод: фронт не должен ожидать безопасных данных с сервера и должен думать про безопасный рендеринг всегда!
Надеюсь, мне удалось убедить фронтендеров задуматься про XSS 🤓