В мире современной серверной веб-разработки на TypeScript легковесный фреймворк Hono от Юсуке Вады (Yusuke Wada) занял совершенно особое место. Пока классические гиганты вроде Express несут груз устаревших абстракций Node.js, а Fastify требует специализированных плагинов, Hono изначально строился вокруг открытых веб-стандартов: стандартных объектов Request, Response, потоков ReadableStream и Fetch API.
Благодаря этому приложение на Hono работает буквально везде без изменения единой строчки: в Cloudflare Workers, Deno, Bun, Fastly Compute, на Vercel Edge и в традиционном контейнере с Node.js.
25 октября 2026 года сообщество выпустило минорный патч-релиз Hono v4.13.14. Хотя номер релиза кажется скромным, в нем появились практические улучшения, которые существенно упрощают работу с middleware авторизации, закрывают риски безопасности при раздаче статики и готовят кодовую базу к будущему мажорному переходу на Hono v5.
Давай посмотрим, что изменилось и как применить эти новшества в боевых сервисах.
Кастомный Response в bearerAuth: прощай, лишний boilerplate
Самое заметное нововведение релиза — обновление встроенного middleware авторизации по Bearer-токену (hono/bearer-auth, PR #5269).
Раньше, если клиент присылал невалидный токен или вовсе забывал заголовок Authorization, функция кастомизации сообщения MessageFunction позволяла вернуть только примитивную строку или простой объект, который Hono сам оборачивал в стандартный JSON-ответ. Если API требовало вернуть строгий статус (например, разграничить 401 Unauthorized и 403 Forbidden), добавить кастомный заголовок WWW-Authenticate или выставить служебный идентификатор трассировки X-Request-Id, разработчику приходилось либо реализовывать собственный middleware с нуля, либо городить хрупкие перехваты в app.onError.
С версии v4.13.14 сигнатура MessageFunction официально поддерживает возврат полноценного веб-стандартного объекта Response (или Promise<Response>).
Установка и обновление фреймворка выполняются одной командой:
npm install hono@4.13.14
А вот как теперь выглядит лаконичная и строгая настройка защищенного маршрута:
import { Hono } from 'hono'
import { bearerAuth } from 'hono/bearer-auth'
import { serveStatic } from 'hono/bun' // или hono/cloudflare-workers / @hono/node-server
const app = new Hono()
// Настройка авторизации с возвратом полноценного объекта Response
app.use(
'/api/v1/secure/*',
bearerAuth({
token: 'production-secret-token-xyz',
invalidToken: {
message: (c) => {
// Возвращаем типизированный ответ об ошибке в стандарте RFC 9457
return c.json(
{
type: 'https://example.com/errors/unauthorized',
title: 'Invalid Access Token',
status: 401,
detail: 'Переданный токен авторизации отозван или недействителен',
instance: c.req.path,
},
401,
{
'WWW-Authenticate': 'Bearer error="invalid_token"',
'X-Security-Audit': 'failed-auth-attempt',
}
)
},
},
})
)
// Безопасная раздача статики с учетом сжатия brotli и gzip
app.use(
'/static/*',
serveStatic({
root: './public',
precompressed: true, // учитывает приоритеты q-values в Accept-Encoding
})
)
app.get('/api/v1/secure/data', (c) => {
return c.json({ status: 'ok', data: 'Конфиденциальная информация' })
})
export default app
Код получается декларативным, избавляется от бойлерплейта и сразу отдает браузеру или мобильному клиенту корректные заголовки аудита.
Безопасность статики и экономия трафика по q-values
Второй блок изменений затронул middleware serve-static (PR #5514, PR #5436).
Во-первых, разработчики жестко ограничили список обслуживаемых HTTP-методов: теперь статические файлы отдаются исключительно на запросы GET и HEAD. Любые попытки отправить методы POST, PUT, DELETE или PATCH в сторону статических эндпоинтов немедленно прерываются сервером без лишнего чтения файловой системы. Это закрывает лазейки для атак обхода путей (Path Traversal) и попыток загрязнения кэша на промежуточных прокси. Подобная строгость протокола перекликается с практиками безопасности, которые мы разбирали для бэкенд-фреймворка NestJS с защитой от CSRF.
Во-вторых, добавлен корректный парсинг весовых коэффициентов (q-values) в заголовке Accept-Encoding. Если браузер отправляет заголовок вида gzip;q=0.8, br;q=1.0, Hono корректно выберет предварительно сжатый файл с расширением .br (Brotli), экономя исходящий трафик и ускоряя загрузку первого экрана.
Префиксный роутер и совместимость с будущим Hono v5
Наконец, точечные исправления коснулись производительности ядра. В высокоскоростном роутере на базе префиксного дерева (TrieRouter, PR #5423) исправлена обработка дублирующихся параметров пути: теперь парсер стабильно сохраняет первое совпадение, предотвращая непредсказуемое поведение маршрутизатора. Также поправлена минификация встроенных стилей Hono CSS, где ранее могли удаляться пробелы перед комбинаторами потомков.
А для авторов сторонних библиотек и плагинов официальные адаптеры расширили диапазон peer-зависимостей (PR #5537), открыв возможность тестирования на предрелизных версиях будущего мажорного обновления Hono v5.
Hono v4.13.14 — отличный образец зрелой инженерной гигиены: точечные, безопасные и предсказуемые улучшения без ломки обратной совместимости. Обновляйтесь смело.