Критическая уязвимость в React Server Components (CVSS 10.0). Рекомендуется обновление

🚨 React-команда официально сообщила о серьёзной проблеме безопасности в React Server Components.
Уязвимость позволяет выполнить произвольный код на сервере без аутентификации — достаточно отправить специально сформированный HTTP-запрос.

Даже если вы не используете React Server Functions напрямую — вы всё равно можете быть уязвимы, если ваш проект поддерживает React Server Components.

Уязвимость получила идентификатор CVE-2025-55182, оценку CVSS 10.0, и затрагивает версии 19.0, 19.1.0, 19.1.1 и 19.2.0 следующих пакетов:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

🔘Что делать прямо сейчас

Патч уже опубликован. Нужно обновиться на версии: 19.0.1, 19.1.2, 19.2.1.
Если ваш React-код вообще не работает на сервере, или вы не используете фреймворки/бандлеры с поддержкой RSC, то вы не затронуты.

Некоторые экосистемы зависели от уязвимых пакетов. В зоне риска:

Next.js
React Router (нестабильные RSC-API)
Waku
@parcel/rsc
@vitejs/plugin-rsc
Redwood SDK

Команда React работает с хостинг-провайдерами, и временные смягчения уже включены.
Но на них рассчитывать нельзя — обновляться всё равно нужно.

🔘В чём суть уязвимости

React Server Functions позволяют клиенту вызывать функции на сервере. На стороне клиента вызов превращается в HTTP-запрос, который React затем десериализует и мапит на вызов серверной функции.

Проблема — в том, как React декодирует payload от клиента.
Атакующий может создать вредоносный HTTP-запрос, который при десериализации приводит к удалённому выполнению кода.

Подробности раскроют позже, когда обновления будут полностью раскатаны.

🔘Инструкция по обновлению Next.js

Установите патч в рамках вашей версии:

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7

Если вы сидите на 14.3.0-canary.77 или выше — откатитесь на стабильную 14.x:

npm install next@14

React Router (нестабильные RSC API)

Обновите зависимости:

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

Expo
См. changelog на expo.dev.

Redwood SDK
npm install rwsdk@latest
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Waku
npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

Vite RSC
npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

Parcel RSC
npm install react@latest react-dom@latest react-server-dom-parcel@latest

Turbopack RSC
npm install react@latest react-dom@latest react-server-dom-turbopack@latest

Webpack RSC
npm install react@latest react-dom@latest react-server-dom-webpack@latest

📅 Таймлайн

29 ноября — уязвимость найденa и отправленa в Meta Bug Bounty.
30 ноября — Meta подтвердила и начала работать над фиксом с командой React.
1 декабря — фикc готов, идёт работа с хостингами и OSS-проекта́ми над валидацией и mitigations.
3 декабря — патч опубликован, уязвимость раскрыта публично.

📍 Ссылка на оригинал статьи...

🎭 Как писать фронтенд-API без боли

Когда разрабатываешь фронтенд-API, важно помнить, что это не просто тонкий слой поверх бэкенда. Это полноценный контракт, который определяет, насколько удобным будет продукт, как он будет восприниматься командой и какие проблемы будут возникать в будущем. Вот чеклист, как делать API, которые не только работают, но и легко поддерживаются.

⬆️ Предсказуемость API

Одной из главных проблем является непоследовательность. Разные названия полей, структуры ответов или коды ошибок могут разрушить любые попытки стабильно работать с API. Если разработчик уже сталкивался с одним вашим эндпоинтом, он должен быть уверен, что следующий будет примерно таким же. Это поможет избежать проблем с поддержкой и быстрым внедрением новых функций.

⬆️ Документация, которая работает автоматически

Ручная документация быстро устаревает. Используйте инструменты, которые генерируют документацию автоматически. Применяйте OpenAPI или Swagger, JSON Schema, и автоматическую генерацию TypeScript-типов и клиента. Так API и документация будут всегда в актуальном состоянии, и фронтенд станет намного стабильнее.

⬆️ Стабильность типов

Проблемы начинаются, когда поля данных могут быть как null, так и отсутствовать. Это ломает UI и делает приложение нестабильным. К примеру, лучше иметь всегда однотипную структуру с корректным значением, чем случайные поля с разными типами данных. Убедитесь, что данные всегда стабильны и предсказуемы.

⬆️ Избегайте «магических значений»

Пример плохого API: { "status": 3 }. Какое значение означает 3? Это нечитаемо. Лучше использовать понятные значения, например { "status": "blocked" }. Это снижает количество ошибок, делает API легче в поддержке и чтении, а также повышает понимание со стороны разработчиков.

⬆️ Ошибки — это не просто статус коды

Ошибки должны быть обработаны с умом. Базовые коды ошибок 200 и 500 недостаточны для хорошей работы. Вместо этого используйте чёткие коды ошибок с описанием. Например, если сессия истекла, верните:

{
"error": {
"code": "INVALID_TOKEN",
"message": "Token expired"
}
}

Это поможет сделать более эффективное восстановление сессий, ретраи и улучшит UX.

⬆️ Когда пишете API, учитывайте, что фронтенду важно:

• Меньше мелких запросов
• Возможность кэширования
• Нормализованные данные
• Компактные ответы
• Фронтенд не любит, когда API возвращает огромные ответы с лишними данными. Помните о пагинации, батчинге и стабильных ETags для ресурсов.

⬆️ Давайте всё, что нужно для кэширования

API должно поддерживать кэширование. Используйте такие механизмы, как ETag, Cache-Control, Last-Modified и max-age. Это позволяет фронтенду эффективно использовать кэш, уменьшить нагрузку и ускорить работу.

⬆️ Защищайте от over-fetching и under-fetching

Убедитесь, что API не отправляет лишние данные (over-fetching), например, если вам не нужны роли пользователей или их настройки. Также не стоит заставлять фронтенд делать несколько запросов для получения нужных данных (under-fetching). Используйте view-модели, которые заточены под конкретные UI-экраны.

⬆️ Осознанно подходите к версионированию API

Версионирование API должно быть осознанным. Простой путь с номерами версий /v2, /v3 — это ещё не всё. Важно обеспечивать совместимость внутри каждой версии и предусматривать возможность отката. Версионирование должно быть предсказуемым и чётким.

⬆️ Создайте клиентскую обёртку

Фронтенд должен самостоятельно решать такие задачи, как ретраи, отмена запросов, debounce, тайм-ауты и токен-логика. Это не должно быть задачей бэкенда. Создайте единый слой API для клиента с помощью custom fetch wrapper, axios instance или TanStack Query. Один класс для всех запросов поможет добиться более стабильного поведения и улучшить контроль над запросами.

📌 Крутое фронтенд-API — это не просто набор точек входа, а целая система, которая должна быть предсказуемой и стабильной. Давайте создавать API, которое не ломает фронтенд, а упрощает жизнь всей команде.

🚪 Frontender's notes

❌ 10 ошибок в lazy-loading, которые замедляют сайт

Недавно мы писали про lazyLoading в этом посте. Продолжаем тему

Ленивая загрузка — это отличная технология для оптимизации производительности. Однако, при неправильном применении она может привести к замедлению работы сайта, а не улучшению. Я всё чаще сталкиваюсь с одними и теми же ошибками, которые разработчики продолжают допускать. Вот список ошибок, которых стоит избегать, чтобы сделать ваш сайт быстрее и плавнее.

❌ Ленивая загрузка критичного UI

Когда речь идёт о компонентах, которые напрямую влияют на первый экран, интерактивность навигации или основные кнопки и инпуты, их нельзя загружать лениво. Ленивая загрузка не должна касаться того, что важно для начальной интерактивности сайта. Такие элементы должны быть готовы к использованию как можно раньше.

❌ Грузить код лениво, но слишком поздно

Ошибка, с которой сталкиваются многие: компонент загружается лениво, но нуждается в немедленной активации. Из-за этого возникает задержка, и пользователь видит лаги или мерцание. Чтобы избежать этого, используйте предзагрузку (prefetch) вместе с ленивой загрузкой.

<link rel="prefetch" href="/modal.js">

❌ Ленивое загружение там, где нужна отложенная инициализация

Некоторые операции, такие как работа с картами, сложными таблицами или WebGL, требуют, чтобы код был загружен сразу, но его выполнение можно отложить. Для этого используйте requestIdleCallback, setTimeout(0) или Scheduler API.

❌ Ленивая загрузка маленьких модулей

Если модуль весит 1-3 KB, разбивать его на отдельный чанк — это лишняя нагрузка. Модули такого размера не нужно загружать лениво, так как это добавит ненужные сетевые запросы и усложнит граф зависимостей. Ленивая загрузка должна применяться только к тяжелым и ресурсозатратным модулям.

❌ Ленивая загрузка без учета поведения пользователя

Ошибка заключается в том, что модалки или другие элементы функционала загружаются лениво, даже если пользователь почти сразу же взаимодействует с ними. В 2025 году есть инструменты, как prediction-preload в Next.js, Astro или Remix, которые помогают предугадывать действия пользователя и загружать необходимые компоненты заранее.

❌ Ленивая загрузка изображений без настроек fetchpriority

Когда изображения загружаются лениво, они могут быть исключены из нормального потока загрузки, что может привести к исчезновению важного контента с экрана. Используйте fetchpriority="high" для ключевых изображений, чтобы они загружались первыми.

<img src="hero.jpg" loading="eager" fetchpriority="high">
<img src="section.jpg" loading="lazy">

❌ Ленивая загрузка CSS и блокировка first-paint

При ленивой загрузке тем и дополнительных стилей можно столкнуться с проблемой «unstyled flash» — когда контент появляется без стилей. Чтобы этого избежать, применяйте технику ленивой загрузки для стилей:

<link rel="stylesheet" href="theme.css" media="print" onload="this.media='all'">

❌ Ленивая загрузка маленьких иконок и SVG-спрайтов

Ленивая загрузка маленьких графических ассетов, таких как иконки или SVG-спрайты, приводит к лишним сетевым запросам, но почти не экономит ресурсы. Вместо этого используйте inline SVG, спрайты в <defs>, или пакуйте через Vite или Next.js.

❌ Неправильный threshold в IntersectionObserver

Если вы ставите threshold слишком низким, например, компонент загружается только когда он вошел на 1 пиксель в видимую область, пользователь может увидеть задержку в подгрузке контента. Лучше использовать более высокий порог, чтобы загружать элементы заранее, например:

new IntersectionObserver(callback, { rootMargin: '200px' });

❌ Отсутствие fallback UI

Когда чанк ещё грузится, а пользователь уже видит пустое пространство, это создаёт ощущение тормозящего приложения. Чтобы этого избежать, всегда добавляйте skeletons, placeholders, мини-лоадеры или заранее зарендеренные контейнеры. Это сделает загрузку более плавной и улучшит восприятие приложения.

📌 Правильная ленивая загрузка — это не просто отложить всё на потом. Это умение понять, что можно подождать, а что лучше сразу загрузить.

🚪 Frontender's notes

🔫 CI/CD для фронтенда: как сделать процессы безболезненными

Когда проект растёт, настоящая боль для команды не всегда в коде, а в процессе CI/CD. Долгие сборки, случайные ошибки, непонятные артефакты — всё это превращается в ежедневную головную боль. Однако, правильно настроенная система CI/CD может быть гораздо проще и эффективнее, чем кажется.

👨‍🎨 Линтить → тестировать → билдить

Частая ошибка команд — начинать с билда и только потом замечать пропущенные ошибки. Это может привести к ситуациям, когда сборка занимает 5 минут, а где то одна недостающая запятая. Правильный порядок: линтинг с ESLint и TypeScript, юнит-тесты, E2E и интеграционные тесты, и только потом билд. Так вы сэкономите время и ресурсы.

⚡️ Кеш — ваш лучший друг

Использование кеша для ускорения процессов стало нормой. Не стоит недооценивать его влияние на скорость работы. Настроенные кеши в pnpm, npm, yarn, Turbo, Nx, Bun, Vite, и GitHub Actions помогут значительно ускорить процессы и сократить время на каждом пуше.

🗳 Разделяйте CI и CD

CI (Continuous Integration) и CD (Continuous Deployment) — это два разных процесса. CI отвечает на вопрос: «Можно ли собрать код и пройти тесты?» CD же решает, готов ли код к деплою в продакшн. Когда эти процессы объединяются в один пайплайн, только добавляется хаос.

💡 Feature Environments

Каждая ветка должна иметь свою отдельную превью-среду, как например в Vercel, Netlify, Cloudflare Pages или Render. Это помогает PM увидеть изменения до мерджа, QA не зависеть от локальных настроек, а дизайнерам проверять анимации. Без этой практики рецензировать UI-фичи становится крайне сложно.

🔄 Деплой должен быть атомарным

Каждый коммит должен приводить к одному артефакту и одному деплою. Без «подправил на сервере» и «почему на проде другая версия файла?». Артефакты должны быть воспроизводимыми, неизменяемыми и версионируемыми.

❌ Прерывание старых джобов

При каждом новом пуше в PR старые CI процессы должны отменяться, чтобы избежать лишних билдов подряд. Это можно настроить в GitHub Actions с помощью простого конфигурационного кода.

📦 Проверка бандла — часть CI, а не когда вспомним

Проверка бандла на каждом этапе CI с помощью таких инструментов как Bundlephobia API, Webpack Bundle Analyzer, Lighthouse-ci поможет избежать случайных увеличений размера бандла.

🤚 Rollout фичей — через feature flags

Деплой не всегда означает релиз. Фича-флаги позволяют постепенно выкатывать изменения, откатывать без деплоя, тестировать экспериментальные сценарии и проводить A/B тестирование.

🔄 Автоматический откат

Настройте автоматический откат на таких платформах, как Cloudflare или Vercel, чтобы обеспечить стабильность в случае ошибок.

💼 CI/CD должен быть другом, а не врагом

Настоящая система CI/CD должна работать без вашего вмешательства, обеспечивая предсказуемость, скорость и спокойствие для команды.

📌 CI/CD не просто про автоматизацию, это про создание комфортной среды для разработчиков. Правильно настроенная система CI/CD ускоряет процесс разработки и помогает команде работать с минимальными проблемами.

🚪 Frontender's notes

😎 Найдено самое оригинальное портфолио

Чтобы узнать о навыках и опыте работы, нужно исследовать остров и дом разработчика. Можно также взаимодействовать с предметами, приручить утку, написать разрабу письмо через почтовый ящик и попытаться вытащить меч короля Артура.

Все ассеты, кстати, тоже сделаны с нуля.

✖️ xCode Journal

❗️ Memory leaks в браузере: как не упустить реальную проблему

Утечки памяти в JavaScript — это не только про забытые таймеры. На самом деле существует множество других скрытых причин, которые могут годами «поглощать» память. Даже опытные разработчики часто упускают эти моменты, которые становятся источниками утечек в продакшене. Сегодня разберем, какие типичные ошибки приводят к утечкам памяти и как их избегать.

❌ Зависшие ссылки в замыканиях

Когда компонент или объект был удалён, но замыкание всё равно сохраняет ссылку на данные, они не могут быть очищены. Это классическая ошибка, особенно при больших данных.

Проблема (в примерах): bigData остаётся в памяти, пока существует ссылка на колбэк.

❌ Глобальные переменные

Ошибки с глобальными переменными часто возникают, когда забывают использовать const или let.

Проблема (в примерах): Любой объект в глобальной области будет жить вечно.

❌ Слушатели событий и DOM-узлы

Если слушатели событий или DOM-узлы не удаляются после того, как элементы были удалены, это может привести к утечкам. Особенно часто это случается с модальными окнами или кастомными компонентами.

Проблема (в примерах): После удаления элемента слушатель остаётся, удерживая объект в памяти.

❌ Неправильное использование таймеров

Таймеры типа setInterval, которые не очищаются при уходе со страницы, могут продолжать работать, удерживая тяжёлые данные.

Проблема: Таймер продолжает работать, сохраняя контекст.

❌ Неправильное использование таймеров

Таймеры, такие как setInterval, могут стать серьезным источником утечек памяти, если не очищаются при уходе со страницы или продолжают ссылаться на контекст.

Проблема: Таймер продолжает работать, удерживая тяжелые данные в замыкании, даже после того, как компонент был размонтирован.

❌ Кэши без лимитов

Попытки сделать «умное кэширование» без ограничений на размер могут привести к утечкам.

Проблема (в примерах): Без лимитов на кэш память будет заполняться бесконечно.

❌ Проблемы с Web Workers

Ошибки в работе с Web Workers, такие как передача данных без Transferables или не закрытые воркеры, могут стать причиной утечек.

❌ Сторонние библиотеки

Некоторые библиотеки, особенно для UI, могут создавать скрытые DOM-структуры и не очищать их по завершении работы, что также ведет к утечкам.

❌ React: stale effects

В React утечки могут происходить из-за старых ссылок в эффектах, которые не пересоздаются.

Проблема (в примерах): Эффект не пересоздается, старые ссылки остаются.

📝 Примеры

// Зависшие ссылки в замыканиях
function createTracker() {
const bigData = new Array(1_000_000).fill('x');
return () => console.log(bigData.length);
}

// Глобальные переменные
foo = {}; // теперь это window.foo

// Слушатели событий и DOM-узлы
element.addEventListener('scroll', handler);
// element.removeEventListener(...) забыли

// Кэши без лимитов
const cache = {};
cache[key] = heavyObject;

// React: stale effects
useEffect(() => {
subscribe();
return () => unsubscribe();
}, []); // но зависимость должна быть!

📌 Для обнаружения утечек памяти используйте Chrome DevTools. Перейдите в Performance → Memory Leak Check и проанализируйте Heap snapshots и Allocation Timelines. Обращайте внимание на Detached DOM nodes и Large object groups. Утечка памяти происходит, когда объект больше не нужен, но на него всё ещё есть ссылка. Иногда это баг, который длится месяцами.

🚪 Frontender's note

📖 JSCamp

JSCamp — это полный интенсив, который проведет вас через все основные технологии экосистемы JavaScript, включая HTML, CSS, JavaScript, TypeScript, Node.js, SQL, CI/CD и Docker.

Этот курс — отличная возможность создать настоящий проект с нуля. Это не только поможет закрепить все, что вы узнали, но и добавит крутое приложение в ваше портфолио.

📌 А сам курс довольно понятный и доступный. Видео и материалы будут потихоньку появляться на платформе JSCamp.dev, так что сможете вернуться к ним, когда захотите.

🔘Есть нюанс. Репа на испанском, придется работать с переводчиками если вы его не знаете.

🚪 Frontender's notes

💡 Чеклист для ревью фронтенд-кода

Когда фронтенд-проект растет, качественное ревью кода может спасти не только часы работы, но и нервные клетки. Это не просто проверки на стиль, а конкретный список проверок, которые помогут улучшить производительность, UX и облегчить поддержку. Делюсь проверенным чеклистом для команд.

💬 Архитектура и структура

Первое, на что стоит обратить внимание — это структура кода. Логика должна быть разделена по слоям, например, ui, features, services, libs. Не должно быть гигантских файлов на 500 строк и больше, а импорты не должны образовывать циклических зависимостей. Код должен быть логично организован и легко поддерживаем. Особое внимание стоит уделить отсутствию общих утилит, которые непредсказуемо тянут лишний код.

💬 Чистота и читаемость

Код должен быть понятен без дополнительной документации. Названия сущностей и функций должны четко отражать их назначение, избегайте абстрактных сокращений типа a, b, c, если это не map или reduce. Логика функций не должна выходить за пределы одного экрана. Убедитесь, что мусорные console.log удалены из финальной версии.

💬 Работа с состоянием

Стейт должен быть локализован в компоненты и в стор, не стоит размывать его между ними. Нужно следить за тем, чтобы не было лишних перерендеров, а также чтобы useMemo и useCallback использовались только по делу. Эффекты должны быть грамотно настроены, чтобы не вызывать побочные действия из-за неправильных зависимостей, а бесконечные циклы useEffect — это то, что нужно избегать.

💬 Асинхронность

Везде должны быть учтены ошибки с использованием try/catch или .catch. Важно следить за гонками состояний и отменой запросов через AbortController или аналоги. Промисы не должны «висеть», и все ошибки должны быть разделены на ошибки пользователя и сервера.

💬 Производительность

Избегайте ненужных рендеров и перерасчетов layout, таких как работа с DOM вне циклов или синхронные запросы типа offsetWidth. Большие списки должны быть под виртуализацией. Оптимизируйте циклы и тяжелые вычисления, и если нужно — выносите их в Web Worker. В JSX не должно быть больших inline-функций, а ререндеры не должны происходить из-за лишних контекстов.

💬 Работа с памятью

Все таймеры должны быть очищены, и слушатели событий удаляться при очистке. Не должно быть бесконтрольных кэшей, утечек из-за замыканий или устаревших эффектов. Важно также следить за тем, чтобы не было «висячих» DOM-нод (detached nodes).

💬 Безопасность

Важно исключить прямую вставку HTML через dangerouslySetInnerHTML. Все входные данные должны быть валидированы, чтобы избежать утечек токенов в логах. Работа с localStorage и cookies должна быть безопасной, а ключи и секреты не должны быть жестко закодированы в проекте.

💬 Работа с API

API должно быть ясным и с четко определёнными DTO/типами для запросов и ответов. Ошибки от сервера должны обрабатываться отдельно от пользовательских. Избегайте "магических строк", а также убедитесь в правильности заголовков, методов и кодов ответа. Не должно быть повторяющихся запросов, которые должны быть мемоизированы или дедуплицированы.

💬 UI и UX

Все загрузочные состояния, такие как loading, error, empty, должны быть правильно реализованы. Спиннеры не должны прыгать по экрану. Весь интерактивный контент должен быть доступен для пользователей с ограниченными возможностями (accessibility), а layout shift не должен происходить при загрузке. Анимации должны быть легкими и не блокирующими.

💬 Тестируемость

Код должен быть легко тестируемым, а компоненты не завязаны на глобальные состояния. Логика должна быть вынесена из JSX, а побочные эффекты должны быть минимизированы. Мокинг зависимостей должен быть простым и удобным. Покрытие тестами важно, но не должно быть самоцелью — главное, чтобы тесты действительно проверяли функциональность, а не просто увеличивали процент покрытия.

📌 Чеклист поможет вам избежать распространённых ошибок при работе. Когда код соответствует этим критериям, он становится проще, быстрее и стабильнее.

🚪 Frontender's notes

🤩 Cursor добавили визуальный редактор UI прямо во встроенный браузер IDE!

Работает элементарно — просто берешь и перетаскиваешь элементы, меняешь стили, центруешь div (даже это теперь с ИИ), а Cursor сам обновляет весь код под капотом.

✖️ xCode Journal