React Server Components уязвимости: чему научила громкая история с RSC
История с уязвимостями React Server Components — хороший повод поговорить о зависимости modern frontend от серверного runtime.
React Server Components сделали фронтенд ближе к серверу. Это удобно: меньше клиентского JavaScript, новые паттерны загрузки данных, плотная интеграция с фреймворками. Но когда фронтенд-функция начинает исполняться на сервере, риски тоже становятся серверными.
Главный урок
Современный frontend уже не всегда "просто статика". Next.js, RSC, server actions, middleware и SSR превращают часть фронтенда в backend-поверхность. Значит, обновления безопасности фреймворка становятся такими же важными, как обновления PHP, Node.js или nginx.
Что стоит делать в проектах
- следить за advisories фреймворка;
- не держать старые major без причины;
- иметь быстрый путь обновления;
- не отключать lockfile discipline;
- проверять, что production реально обновился, а не только package.json.
Почему маленькие проекты тоже в зоне риска
Чем меньше проект, тем чаще он обновляется вручную и нерегулярно. "Работает — не трогай" звучит логично, пока не выходит критическая уязвимость в широко используемом серверном механизме.
Вывод
RSC — не плохая идея. Просто она напоминает: если код исполняется на сервере, его нужно сопровождать как серверный код. Даже если выглядит он как React-компонент.
Источник: React security posts.