Experimental node:ffi: почему это мощно, но опасно
В Node.js появился экспериментальный FFI-модуль. Он открывает дверь к нативным библиотекам, но вместе с ней приносит классические риски C.
В Node.js 26.1.0 появился экспериментальный node:ffi. Идея простая: дать JavaScript-коду вызывать функции из нативных динамических библиотек. Для некоторых задач это очень удобно: не нужно писать отдельный addon, можно быстрее связать Node.js с уже существующей C/C++ библиотекой.
Но удобство здесь не бесплатное.
Почему FFI опаснее обычного npm-пакета
Обычный JavaScript может упасть, съесть память или повесить event loop. FFI может сделать хуже: неправильный указатель, неверная сигнатура, обращение к освобожденной памяти — и процесс падает или ведет себя непредсказуемо.
Это уже не привычный мир JavaScript, где runtime многое контролирует. Это мост в нативный код со всеми последствиями.
Где FFI может быть оправдан
- интеграция со старой библиотекой;
- быстрый прототип перед нормальным native addon;
- внутренние инструменты;
- задачи, где есть жесткий контроль над окружением.
А вот давать пользователю косвенно влиять на то, какие библиотеки вызываются и с какими аргументами, — плохая идея.
Что проверить перед использованием
- включена ли модель разрешений;
- кто контролирует путь к библиотеке;
- валидируются ли аргументы;
- есть ли изоляция процесса;
- что будет при падении.
Вывод
node:ffi — не игрушка для каждого проекта. Это полезный инструмент для взрослых интеграций, но его стоит держать подальше от публичного ввода и критичных процессов без изоляции.
Источник: Node.js 26.1.0 release.