OWASP Top 10

Fresh — серверный фреймворк для Deno, построенный вокруг концепций islands architecture, строгой типизации и минимального JavaScript на клиенте. За счёт отсутствия бандлинга, прямого использования ES-модулей и рендеринга на сервере Fresh по умолчанию снижает часть типичных рисков, однако не устраняет их полностью. Модель угроз для Fresh-приложений напрямую соотносится с OWASP Top 10, и каждая категория уязвимостей проявляется с учётом особенностей Deno и самого фреймворка.

A01: Broken Access Control

В Fresh маршруты реализуются через файловую систему (routes/), а серверный код выполняется напрямую в обработчиках Handlers. Отсутствие централизованного механизма авторизации увеличивает риск ошибок контроля доступа.

Типичные проблемы:

  • отсутствие проверки прав пользователя в обработчиках GET, POST, DELETE;
  • полагание только на клиентскую логику islands;
  • прямой доступ к маршрутам API без middleware.

Пример потенциально уязвимого обработчика:

export const handler: Handlers = {
  async GET(req, ctx) {
    const userId = ctx.params.id;
    return new Response(await getUserData(userId));
  }
};

Отсутствует проверка:

  • аутентификации;
  • соответствия userId текущему пользователю;
  • роли или уровня доступа.

Корректный подход предполагает:

  • серверную проверку сессии или токена;
  • централизованный middleware в routes/_middleware.ts;
  • строгую проверку прав на уровне обработчиков.

A02: Cryptographic Failures

Fresh не навязывает криптографические библиотеки. В Deno доступны стандартные Web Crypto API, но ошибки часто связаны с неправильным использованием.

Распространённые нарушения:

  • хранение паролей в открытом виде;
  • использование устаревших алгоритмов (MD5, SHA-1);
  • отсутствие HTTPS при работе с cookies;
  • самописное шифрование.

Пример неверного хранения пароля:

await db.insert({ email, password });

Безопасная практика:

  • хэширование через bcrypt или argon2;
  • использование crypto.subtle;
  • установка флагов HttpOnly, Secure, SameSite для cookies;
  • обязательное TLS-шифрование.

A03: Injection

Хотя Fresh не использует SQL напрямую, инъекции возможны:

  • в базах данных;
  • в shell-командах;
  • в шаблонах JSX при неконтролируемом вводе.

Опасный пример:

const query = `SELECT * FROM users WHERE email = '${email}'`;

Даже при серверном рендеринге инъекции остаются критичными. JSX не экранирует данные, переданные в dangerouslySetInnerHTML.

Защитные меры:

  • параметризованные запросы;
  • строгая валидация входных данных;
  • отказ от интерполяции пользовательского ввода;
  • минимизация dangerouslySetInnerHTML.

A04: Insecure Design

Fresh облегчает быстрый старт, но архитектурные ошибки возникают на этапе проектирования.

Типичные признаки:

  • отсутствие модели угроз;
  • смешивание бизнес-логики и HTTP-обработчиков;
  • доверие данным из cookies и headers;
  • отсутствие ограничений на количество запросов.

Пример небезопасного дизайна:

  • авторизация через параметр запроса;
  • логика ролей на клиенте;
  • отсутствие rate limiting для API.

Безопасный дизайн включает:

  • чёткое разделение слоёв;
  • серверную проверку всех критичных условий;
  • лимиты запросов и таймауты;
  • отказ от «скрытых» маршрутов как средства защиты.

A05: Security Misconfiguration

Deno и Fresh имеют строгую модель разрешений, но при деплое часто отключаются ограничения.

Распространённые ошибки:

  • запуск Deno с --allow-all;
  • публикация debug-логов;
  • отсутствие CORS-политик;
  • открытые stack traces в ответах сервера.

Пример небезопасного запуска:

deno run --allow-all main.ts

Рекомендации:

  • минимальные разрешения (--allow-net, --allow-env);
  • настройка CORS в middleware;
  • отключение подробных ошибок в production;
  • явная конфигурация окружения.

A06: Vulnerable and Outdated Components

Fresh активно использует внешние ES-модули по URL. Это создаёт уникальный риск.

Проблемы:

  • отсутствие lock-файлов;
  • автоматическое обновление зависимостей;
  • импорт из непроверенных источников.

Пример:

import { something } FROM "https://example.com/lib.ts";

Защита:

  • использование deno.lock;
  • фиксация версий;
  • аудит зависимостей;
  • предпочтение официальных репозиториев.

A07: Identification and Authentication Failures

Fresh не предоставляет встроенной системы аутентификации.

Ошибки:

  • хранение сессий в localStorage;
  • отсутствие ротации токенов;
  • слабые JWT-секреты;
  • отсутствие срока действия сессии.

Опасный подход:

localStorage.setItem("token", jwt);

Безопасная реализация:

  • HttpOnly cookies;
  • короткоживущие access-токены;
  • refresh-токены с серверной проверкой;
  • серверное хранилище сессий.

A08: Software and Data Integrity Failures

Риск возникает при:

  • динамической загрузке кода;
  • CI/CD без проверок;
  • отсутствии подписей артефактов.

Особенность Fresh:

  • прямой запуск кода без сборки;
  • зависимость от внешних URL-модулей.

Меры защиты:

  • контроль хэшей зависимостей;
  • ограничение прав CI;
  • отказ от динамического eval;
  • проверка источников обновлений.

A09: Security Logging and Monitoring Failures

Fresh-приложения часто не имеют централизованного логирования.

Недостатки:

  • отсутствие логов авторизации;
  • игнорирование неудачных попыток входа;
  • отсутствие алертов.

Пример отсутствия логирования:

if (!authorized) return new Response("Forbidden", { status: 403 });

Не фиксируется:

  • IP;
  • user-agent;
  • время;
  • контекст запроса.

Правильный подход:

  • структурированные логи;
  • хранение событий безопасности;
  • интеграция с SIEM;
  • минимизация чувствительных данных в логах.

A10: Server-Side Request Forgery (SSRF)

В Fresh SSRF возможен через:

  • прокси-эндпоинты;
  • загрузку внешних ресурсов;
  • серверные fetch-запросы с пользовательским вводом.

Уязвимый пример:

await fetch(urlFromUser);

Опасности:

  • доступ к внутренним сервисам;
  • утечка метаданных облака;
  • обход сетевых ограничений.

Методы защиты:

  • whitelist доменов;
  • запрет приватных IP-диапазонов;
  • таймауты и лимиты;
  • строгая валидация URL.

Итоговая специфика Fresh в контексте OWASP

Fresh снижает поверхность атак за счёт:

  • server-first архитектуры;
  • отсутствия лишнего JavaScript;
  • строгой модели разрешений Deno.

Одновременно он требует:

  • осознанного проектирования безопасности;
  • ручной реализации аутентификации и авторизации;
  • строгого контроля зависимостей и конфигураций.

OWASP Top 10 полностью применим к Fresh-приложениям, но каждая категория уязвимостей проявляется через призму server-side rendering, islands architecture и экосистемы Deno.

Оглавление