Предыдущие разборы — про WordPress, Битрикс и Tilda — были устроены просто: есть система, у неё есть цена и риски, мы показываем их и предлагаем альтернативу. С Astro так не получится, и это делает разговор интереснее.
Astro — фреймворк, который решает ту же задачу, что и мы, только с другого конца. Его создатели считают, что современные сайты тащат на себе непристойное количество JavaScript, и с этим надо кончать. Мы считаем ровно так же. Поэтому статья будет не про то, чем Astro плох, а про то, где наши пути совпадают и где они расходятся.
А расходятся они в одном месте, и оно неочевидное.
Что Astro делает правильно
Главная идея Astro — «острова». Страница собирается на сервере разработчика в обычный HTML, а JavaScript добавляется только там, где он действительно нужен, и только для этого куска. Не хотите интерактива — не получите ни байта скриптов.
Мы не стали верить на слово и проверили. Развернули чистый проект на последней версии Astro (7.3.5), собрали страницу со списком записей и посмотрели, что получилось на выходе:
- один файл
index.html; - 8 КБ вместе со стилями;
- ноль подключённых скриптов.
Astro делает ровно то, что обещает. Для контентного сайта — блога, документации, каталога, справочника — это честный и хороший результат, и с точки зрения того, что получает посетитель, он почти неотличим от нашего.
Отдельно отметим правильную установку: документация Astro прямо говорит, что фреймворк ориентирован на контент, а не на приложения с насыщенным интерактивом. Инструмент знает свои границы и не притворяется универсальным — это редкость.
Куда делись зависимости
Теперь посмотрим на ту же установку с другой стороны. Вот что скачалось на машину, чтобы получить эти восемь килобайт:
| Что посчитали | Сколько |
|---|---|
| Пакетов установлено | 194 |
| Файлов на диске | 9 219 |
| Вес папки зависимостей | 167 МБ |
| Разных авторов и сопровождающих | 71 |
| Прямых зависимостей у самого Astro | 53 |
Это голый Astro: без темы, без интеграций, без оптимизации картинок, без CMS. Нижняя граница, а не типичный проект. В реальном проекте цифры будут больше.
Здесь важно не поддаться соблазну лёгкого вывода. Это принципиально лучше, чем у WordPress, и вот почему: в WordPress сорок плагинов исполняются на боевом сервере при каждом обращении посетителя. В Astro эти 194 пакета работают на машине разработчика в момент сборки, а на сервер уезжает результат — статические файлы. Посетитель с ними не встречается никогда.
Разница настоящая и большая. Но зависимости не исчезли — они переехали. И у места, куда они переехали, есть своя история проблем.
Атака на сборку вместо атаки на сайт
В сентябре 2025 года в экосистеме npm произошло то, что потом назвали червём Shai-Hulud. Схема была такой: фишинговое письмо от имени npm с просьбой обновить двухфакторную аутентификацию, кража токена разработчика, а дальше самое интересное — вредоносный код автоматически внедрялся в другие пакеты этого же автора и публиковался от его имени.
Червь искал и забирал: токены npm, ключи доступа к GitHub, SSH-ключи, учётные данные облаков Amazon, Google и Microsoft. Украденное выкладывалось в публичные репозитории. Ноябрьская волна того же года затронула, по оценке Unit 42, десятки тысяч репозиториев — около 25 000 вредоносных репозиториев примерно у 350 учётных записей. Среди скомпрометированных был пакет с миллионами загрузок в неделю.
Обратите внимание на смену цели. При атаке через polyfill.io, о которой мы писали раньше, страдал посетитель сайта. Здесь страдает разработчик: его ключи, его облако, его доступы к чужим проектам. Сайт при этом может остаться нетронутым — а может получить закладку при следующей сборке.
Это не претензия к Astro. Это свойство любой экосистемы, где проект начинается с установки двухсот пакетов от семидесяти незнакомых людей. Astro здесь не хуже и не лучше остальных — он просто в ней живёт.
История уязвимостей самого Astro
В базе Patchstack на сегодня 27 исправленных уязвимостей Astro. Для сравнения масштабов: это не одиннадцать тысяч, как в экосистеме WordPress за год, и подавляющее большинство закрывается быстро. Но список не пустой, и в нём есть интересное.
Самое показательное — исследование, опубликованное в ноябре 2025 года. Astro собирал адрес запроса из заголовков x-forwarded-proto и x-forwarded-port, не проверяя их содержимое. Подставив в такой заголовок специально составленное значение, атакующий переписывал весь адрес целиком. Из этого выросли сразу три разных последствия:
- обход защиты маршрутов — проверка пути в middleware происходила раньше, чем адрес приводился к окончательному виду, и закрытые разделы открывались;
- SSRF — сервер можно было заставить обращаться к адресам, которые выбрал атакующий;
- хранимый XSS — через отравление кэша.
Уязвимость получила номер CVE-2025-64525. Отчёт отправили 3 ноября 2025 года, исправление вышло 10 ноября — команда Astro отреагировала за неделю, и это хорошая скорость.
Но вот принципиально важная оговорка, без которой всё сказанное выше вводит в заблуждение. Почти все эти уязвимости касаются серверного режима работы. Если ваш сайт на Astro — чистая статика, то на сервере не выполняется никакой код Astro, читать заголовки некому, и большинство этих проблем вас не касается вовсе.
И здесь проходит главная развилка.
Развилка: статика или сервер
Astro умеет работать в двух режимах, и с точки зрения безопасности это два совершенно разных продукта.
Статическая сборка (SSG). На сервере лежат готовые файлы. Взламывать нечего: нет кода, который исполняется по запросу посетителя, нет обработки заголовков, нет базы. В этом режиме Astro очень близок к нашему подходу — фактически мы получаем тот же результат, просто собранный другим инструментом.
Серверный режим (SSR). На сервере работает Node.js с Astro внутри, который обрабатывает каждый запрос. Возвращается вся классическая модель серверных рисков — и вместе с ней те самые заголовки, middleware и обход защиты маршрутов.
Держите это различие в голове, когда будете читать следующий раздел.
EmDash: WordPress, каким он мог бы быть
В сентябре 2026 года Cloudflare выпустила EmDash — открытую CMS на TypeScript и Astro, которую они прямо называют «духовным наследником WordPress». Заявленная цель — решить главную проблему WordPress: плагины.
Скажем сразу: архитектурно это сделано серьёзно, а не на словах. Разберём, что именно там устроено иначе.
- Плагин не исполняется в общем процессе. В WordPress плагин — это PHP-код, работающий с теми же правами, что и ядро: он видит базу, файлы, всё. В EmDash плагин запускается в отдельной изолированной среде на движке V8 — примерно так же, как вкладка браузера отделена от других вкладок.
- Разрешения объявляются заранее. Плагин в манифесте пишет, что ему нужно: например, «реагировать на сохранение материала» и «отправлять почту». Всё, что не заявлено, ему недоступно — ни база, ни файловая система, ни произвольные сетевые запросы. Пользователь видит список разрешений перед установкой, как при установке приложения на телефон.
- Пакеты подписаны. Реестр построен на протоколе AT (том самом, на котором работает Bluesky): публикации подписываются издателем, реестр проверяет соответствие загруженного пакета подписи.
Это честный ответ на реальную проблему, и он гораздо лучше того, что есть в WordPress. Если бы нам пришлось выбирать между WordPress и EmDash для проекта с плагинами, мы бы выбрали EmDash не задумываясь.
Сначала о том, что изоляция действительно снимает, — чтобы не обесценить сделанное. В WordPress у плагина есть попутные полномочия, которых он не просил и которые ему не нужны: соединение с базой целиком, запись в файловую систему, исходящая сеть куда угодно. Поэтому сломанный плагин галереи в WordPress — это не «утекли фотографии», а компрометация всего сайта, закладка в папке загрузок, которая переживёт удаление плагина, и нередко соседние сайты на том же хостинге. Вот это V8-изолят убирает по-настоящему. Даже полностью злонамеренный плагин в EmDash не получит shell, не запишет файл, не полезет в чужие данные, не закрепится в системе и не переползёт на соседний проект.
Теперь оговорки.
Продукту месяц. Версия 1.0 вышла в сентябре 2026 года. Любая система плагинов на старте выглядит защищённой — проблемы появляются на третий год, когда накапливаются заброшенные модули, а авторы теряют интерес и продают проекты. Судить об EmDash можно будет в 2029 году, не раньше.
Песочница ограничивает плагин выданными правами, но не уменьшает сами права. Это главное, и это стоит разобрать на примере. Допустим, интернет-магазин, и в нём плагин оформления заказа. По самой своей функции он обязан работать с данными покупателей и заказов — иначе он не плагин оформления заказа. Значит, вы это разрешение выдали. Значит, злоумышленник, получивший контроль над плагином, получает те же данные вместе с ним — через штатное API, не взламывая никакую изоляцию. Для статьи 13.11 КоАП разницы между «украли базу через уязвимость» и «прочитали базу по выданному разрешению» нет: утечка персональных данных покупателей, оператор — вы.
И на самом деле всё ещё жёстче. Для такого плагина дело даже не в доступе к хранилищу, а в том, что данные проходят через него. Имя, телефон, адрес доставки, состав заказа вводятся в его форму и обрабатываются его кодом. Даже если бы модель разрешений была идеально мелкой и позволила выдать ему только право создавать заказ, без чтения истории, — он всё равно видит каждый новый заказ в момент ввода и может отправлять его себе. Изоляция хранилища бессмысленна для кода, который стоит на пути данных: через полгода у атакующего будет та же база, просто собранная в реальном времени.
Подпись отвечает не на тот вопрос. Криптографическая подпись в реестре подтверждает, что релиз действительно опубликован владельцем пакета, — а не что этот релиз безопасен. В сценарии, который на самом деле происходит чаще всего, никто ничего не взламывает: автору популярного плагина проект надоел, и он его продал. Новый владелец и есть легитимный публикатор — он подписывает вредоносное обновление настоящим ключом, реестр его принимает, автообновление ставит. В WordPress это отработанная схема: покупают плагин с сотней тысяч установок, через месяц выпускают «исправление совместимости». Подпись эту схему не ломает, она её заверяет.
Есть и третий сценарий, самый вероятный и самый скучный: плагин никто не ломает и никто не продаёт. Автор просто решает монетизировать проект — добавляет «аналитику покупательского поведения». Разрешение на отправку данных наружу вы выдали сами при установке, потому что без него плагин не работал. Формально всё честно. Для вас это трансграничная передача персональных данных без уведомления регулятора.
Работа по-прежнему на вас, просто другая. Модель EmDash меняет вопрос «что может сделать сломанный плагин» — в WordPress ответ «всё» — на вопрос «что вы выдали каждому плагину и правильно ли вы это решили». Это лучше, потому что ответ стал хотя бы обозримым и объявленным: манифест видно до установки, и обновление, которое вдруг просит больше, в принципе заметно. Но это требует читать манифесты, понимать последствия каждого разрешения, следить за сменой владельцев пакетов и сверять права при обновлениях. Опыт мобильных приложений показал, чем такая модель заканчивается: люди нажимают «разрешить» не читая.
Это серверный режим. EmDash работает на Cloudflare Workers или на Node.js, то есть возвращает нас в правую колонку предыдущего раздела — со всей серверной моделью рисков.
Практический вывод из этого получается не «изоляция не нужна», а более узкий. Изолировать модули стоит там, где они периферийны: галерея, карта, календарь, выгрузка в Excel. Там, где персональных данных нет и цена ошибки — испорченный блок на странице. А оформление заказа, оплату и личный кабинет отдавать наружу нельзя вообще — ни в песочницу, ни без неё. Не потому, что песочница плохая, а потому, что она защищает не то, что в этом месте нужно защитить.
И любопытная деталь: обосновывая необходимость изоляции, Cloudflare ссылается на то, что до 96% проблем безопасности WordPress-сайтов приходится на плагины. Это та же статистика, которую мы приводили в разборе WordPress. Мы с ними согласны в диагнозе — расходимся в лекарстве.
Как это выглядит на реальном сайте
Мы замерили живой сайт на Astro — тот самый контентный проект, с которого и начался этот разбор. Название не приводим: претензий к нему у нас нет, он нужен как пример аккуратной работы, а не как объект критики. Для сравнения — наша главная, замеренная тем же способом, и для масштаба цифры из предыдущих статей.
| Запросов | Вес | JavaScript | Чужих доменов | |
|---|---|---|---|---|
| Сайт на Astro | 45 | 981 КБ | 364 КБ | 0 |
| g3a.ru | 7 | 135 КБ | 9 КБ | 0 |
| Сайт на Tilda | 114 | 2,55 МБ | 411 КБ | 0 |
| Сайт на Битриксе | 97 | 2,84 МБ | 949 КБ | 4 |
Сначала оговорка о том, что здесь вообще сравнивается. В первой строке — контентный проект с сотнями материалов, поиском и плеером, а у нас на главной шесть новостей. Сравнивать так объём работы было бы нечестно, и мы этого не делаем: все четыре величины в таблице относятся к одному просмотру одной страницы, а вес страницы и число запросов от количества статей на сайте не зависят. Страница статьи на сайте с пятьюстами тысячами материалов весит ровно столько же, сколько на сайте с шестью. Так что таблица измеряет не «кто больше написал», а другое: сколько браузер посетителя тратит, чтобы показать ему один экран текста.
Обратная сторона тоже есть, и она в нашу сторону. Будь у нас не шесть материалов, а пятьсот тысяч, наше хранение новостей в файлах пришлось бы менять: каталог такого размера не читают на каждый запрос, понадобился бы индекс или база. Astro для таких объёмов подходит лучше, и ниже в разделе «Когда что выбирать» мы об этом прямо говорим.
Теперь два наблюдения, и оба честные.
Ноль чужих доменов. Это отлично, и это ровно то, за что мы агитируем: ничего не подгружается со стороны, данные посетителей никуда не утекают. По этому показателю Astro-сайт ведёт себя так же, как наш, и заметно лучше среднего сайта в рунете.
364 КБ JavaScript при «нуле по умолчанию». Это не упрёк автору сайта: у него полнотекстовый поиск, аудиоплеер и прочий интерактив, и каждый остров тянет свой код. Это иллюстрация того, что «по умолчанию» и «в итоге» — разные вещи. Умолчание у Astro правильное, но живой сайт всё равно приходит к сотням килобайт скриптов, потому что функциональность из воздуха не берётся.
Стоимость владения: темп версий
Есть ещё один параметр, который не виден на старте, но виден через три года. Вот когда выходили мажорные версии Astro:
| Версия | Дата выхода |
|---|---|
| Astro 1.0 | август 2022 |
| Astro 2.0 | январь 2023 |
| Astro 3.0 | август 2023 |
| Astro 4.0 | декабрь 2023 |
| Astro 5.0 | декабрь 2024 |
| Astro 6.0 | март 2026 |
| Astro 7.0 | июнь 2026 |
Семь мажорных версий за четыре года. При этом в документации сказано прямо: исправления безопасности выпускаются только для одной предыдущей мажорной версии.
Посчитайте, что это значит на практике. Сайт, собранный в декабре 2024 года на Astro 5, сегодня уже не получает исправлений безопасности: текущая версия — седьмая, поддерживается шестая. Прошло меньше двух лет.
Это не упрёк качеству — Astro развивается быстро, и для многих это плюс. Но если сайт делается и забывается на пять лет, такой темп означает, что через пару лет вам предстоит либо обновление с переписыванием, либо жизнь на неподдерживаемой версии. Для статического сайта второе не смертельно, для серверного — уже неприятно.
А теперь про AI, из-за которого всё меняется
Мы подходим к самому интересному. Вся конструкция «поставь плагин» — что в WordPress, что в EmDash — выросла из экономики, которой больше нет.
Логика была железной. Нужна форма заявки с валидацией, отправкой на почту и защитой от спама? Своими руками это неделя работы разработчика. Готовый плагин — пять минут и ноль рублей. Выбор очевиден, и спорить с ним было глупо: никакая теоретическая безопасность не оправдывала недели работы ради формы.
Сегодня та же форма пишется за пару часов вместе с проверкой. Экономическое основание, на котором держалась вся индустрия плагинов, просело — и это, пожалуй, главное изменение в веб-разработке за последние годы, о котором почему-то мало говорят.
Но здесь легко впасть в противоположную крайность, и мы не будем делать вид, что всё стало прекрасно. Код, написанный нейросетью, небезопасен сам по себе, и данные на этот счёт неприятные.
- По исследованию Veracode, 45% сгенерированного ИИ кода содержит уязвимости из списка OWASP Top 10. Отдельно по типам: 86% образцов уязвимы для межсайтового скриптинга.
- По данным, собранным Cloud Security Alliance, разработчики с ИИ-помощником выпускают код в три-четыре раза быстрее — и вместе с ним получают в десять раз больше замечаний по безопасности.
- Синтаксических ошибок стало меньше на три четверти, а вот архитектурных изъянов и путей повышения привилегий — заметно больше. Код выглядит чище, а дыры в нём глубже.
Так что аргумент «теперь можно всё написать с помощью ИИ, и это безопаснее плагинов» в лоб не работает. Работает другой, и он тоньше.
ИИ не пишет безопасный код. ИИ убирает экономическую причину тянуть в проект чужую зависимость ради мелкой задачи. Безопасным код делает то, что после ИИ его читает человек, который понимает написанное и отвечает за него.
Вот в чём настоящая разница. Двести строк, которые мы написали с помощью ИИ и прочитали глазами, — это код, за который есть кому отвечать. Сто девяносто четыре пакета от семидесяти одного автора — это код, который не прочитает никто и никогда, и отвечать за него тоже некому.
Если же вы генерируете нейросетью тысячи строк и выкладываете их не читая, вы просто поменяли один чёрный ящик на другой — причём на более свежий, который не проходил через годы чужих глаз. Это хуже, а не лучше плагина.
Сводка
| Astro (статика) | Наш подход | |
|---|---|---|
| Что на сервере | только файлы | PHP и MariaDB |
| JS у посетителя | по необходимости | по необходимости |
| Зависимостей при сборке | от 194 пакетов | нет |
| Сборка нужна | да | нет |
| Обновления | мажорные версии часто | только сервер |
| Правка контента | файлы и пересборка | админка |
| Закрытый контур | возможен | возможен |
Связка Astro с EmDash в эту таблицу не помещается, и вот почему: она переводит первый столбец в серверный режим. На сервере появляется Node.js или Workers, к зависимостям сборки добавляются плагины, правка контента переезжает в админку, а закрытый контур становится трудной задачей. По набору свойств это ближе к обычной CMS, чем к статике, — со всеми её удобствами и всеми её рисками.
Когда что выбирать
Astro в статическом режиме — отличный выбор, если у вас контентный проект: блог, документация, справочник, большой каталог статей. Особенно если команда уже живёт в мире JavaScript и любит компонентный подход: вы получите знакомые инструменты и при этом лёгкие страницы на выходе. Автор проекта на пятьсот тысяч страниц, который мы читали, готовя эту статью, вполне доволен — и мы понимаем почему.
EmDash стоит смотреть, если вам нужна классическая CMS с плагинами, но пугает история WordPress. Архитектурно это лучшее, что есть в этой нише. Только дайте ему год-другой набрать пробег, прежде чем ставить на него что-то ответственное, — и не отдавайте плагинам работу с персональными данными: там, как мы разобрали выше, изоляция помогает меньше всего.
Наш подход разумен, когда важно другое: чтобы сайт работал годами без обновлений и без сборки, чтобы его можно было развернуть в сети без интернета, чтобы количество движущихся частей стремилось к нулю, а разобраться в коде мог любой PHP-разработчик без изучения фреймворка. Мы платим за это тем, что не пользуемся готовыми компонентами и пишем больше руками, — и в эпоху ИИ эта цена стала заметно ниже.
Итог
С Astro у нас нет спора о диагнозе. Мегабайты JavaScript ради страницы с текстом — это болезнь, и лечить её надо. Разница в том, как далеко каждый готов зайти.
Astro убирает лишний код со страницы посетителя, но оставляет инструментарий: двести пакетов, сборку, темп версий, экосистему npm со всеми её приключениями. Взамен вы получаете удобство разработки, готовые компоненты и скорость работы команды — совершенно реальные вещи, которые многим нужнее, чем наша аскеза.
Мы убираем инструментарий тоже. Наш сайт не собирается — он просто лежит и работает. Обновлять нечего, ломаться нечему, зависеть не от кого. Это медленнее в разработке и скучнее в процессе, зато через пять лет всё будет работать так же, как в первый день.
Оба подхода честные. Просто они отвечают на разные вопросы: «как быстро и удобно делать хорошие сайты» и «как сделать сайт, о котором можно забыть».
Если хотите обсудить, какой из вопросов ваш, — напишите на info@g3a.ru.
Источники
- Замеры выполнены нами 30 сентября 2026 года: чистая установка Astro 7.3.5 и сборка тестовой страницы; замер сайтов — Chromium, пустой кэш, без блокировщика рекламы.
- Уязвимости Astro: база Patchstack.
- Исследование с подменой заголовков: zhero и inzo_, ноябрь 2025.
- Атака на npm: разбор Unit 42, Palo Alto Networks, оповещение CISA.
- EmDash: анонс Cloudflare и описание реестра плагинов в версии 1.0.
- Политика поддержки версий: документация Astro; даты выхода — реестр npm.
- Безопасность кода, написанного ИИ: обзор Cloud Security Alliance со ссылками на исследования Veracode и Apiiro.