Заказчику сайта тоже стоит знать: как пользоваться документом IPA «Как создать безопасный веб-сайт»

«С безопасностью нашего сайта всё в порядке?» — на этот вопрос мало какая компания ответит «да» и сможет это обосновать.

Часто думают: раз сайт делает веб-студия, значит всё хорошо; или что сайт-визитка никому не интересен. Но достаточно одной формы обратной связи — и уже работает программа, которая обрабатывает ввод. Если стоит CMS вроде WordPress, под ударом и панель администратора, и плагины. К тому же атаки чаще не целятся в конкретную фирму: слабые сайты ищут автоматически.

По какому же критерию проверять, что «всё в порядке»? Публичный документ, который давно используют как такой критерий, — «Как создать безопасный веб-сайт» IPA (Information-technology Promotion Agency, Япония).

В этой статье разберём, чему учит этот документ, языком, понятным и заказчику сайта, и тем, кто его эксплуатирует.

1. Сначала вывод

• «Как создать безопасный веб-сайт» — документ, который по реально поступившим в IPA уведомлениям об уязвимостях сводит 11 видов слабых мест сайта и меры против них. Он полезен не только разработчикам: им можно пользоваться и как критерием при заказе и приёмке
• Меры делятся на «устранение причины» (убрать саму причину) и «компенсирующие меры» (снизить ущерб). Основа — устранение причины, компенсирующие меры добавляют поверх него
• Прилагаемый «Чек-лист реализации защиты» можно брать как есть как пункты проверки при заказе у студии и при приёмке
• Отдельное приложение «Спецификация диагностики веб-сайта» задаёт набор пунктов, по которым периодически проверяют уже работающий сайт
• На практике у корпоративного сайта два главных очага риска — места, которые принимают ввод (формы и подобное), и эксплуатация CMS (например, WordPress). Ещё на этапе заказа стоит договориться, кто будет вести сайт после запуска, а не считать работу законченной в день публикации

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 23, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое «Как создать безопасный веб-сайт»

«Как создать безопасный веб-сайт» — документ, в котором IPA для разработчиков и операторов сайтов разбирает уязвимости из поступивших уведомлений: те, по которым заявок было больше, и те, чей ущерб при атаке выше, — и сводит меры против них. Актуальная опубликованная версия — 7-я пересмотренная редакция, 115 страниц. Распространяемый PDF обновлён 31 марта 2021 года как 4-й тираж. Кроме PDF есть HTML-страницы по каждой уязвимости.

Структура — три главы.

Отдельно от основного текста опубликованы ещё такие материалы:

• Чек-лист реализации защиты (Excel): таблица, по которой проверяют, реализованы ли меры из основного текста
• Отдельное приложение «Как безопасно вызывать SQL»: углублённый разбор защиты вокруг базы данных
• Отдельное приложение «Спецификация диагностики веб-сайта»: спецификация из 13 пунктов для проверки уже работающего сайта

Все материалы можно бесплатно скачать со страницы IPA.

2.1. Как относиться к актуальности документа

Прежде чем брать этот документ за критерий, стоит зафиксировать исходные условия. 7-я пересмотренная редакция вышла в марте 2015 года. Дальше в каждом тираже правили текст; PDF, который раздают сейчас, — 4-й тираж 7-й редакции, обновлённый 31 марта 2021 года. На момент написания статьи (июль 2026) 8-й редакции нет.

Документ всё равно годится как критерий, потому что речь в нём о слабых местах, которые следуют из самого способа сборки веб-приложения. Встроить ввод в SQL или HTML, опознать человека по сессии, отправить письмо по данным формы — эти механизмы не изменились. 11 видов уязвимостей и схема «устранение причины / компенсирующие меры» по-прежнему работают как критерий проверки реализации.

Отсюда же следует и ограничение: актуальные тенденции угроз этот документ не покрывает. Атаки программ-вымогателей, проникновение через контрагентов и подрядчиков, риски, связанные с генеративным ИИ, — изначально не его область. Их закрывают документами, которые обновляют каждый год.

Читать все три подряд не нужно. Достаточно разделить роли: «критерий реализации — этот документ, свежие угрозы — „10 главных угроз“, устройство компании — руководство» — и открывать то, что понадобилось. Содержание «10 главных угроз» за 2026 год разобрано в статье о «10 главных угрозах информационной безопасности 2026», редакцию 4.0 руководства — в статье о редакции 4.0.

3. Одиннадцать уязвимостей: что произойдёт, если ничего не делать

11 видов уязвимостей из главы 1 названы терминами для разработчиков. Если переложить их в формулировку «что случится на вашем сайте, если оставить как есть», заказчику уже не кажется, что это чужая проблема.

Правый столбец — примеры мест на корпоративном сайте, где эта уязвимость чаще всего всплывает. Есть ли у вас такая функция — по ней видно, какие строки про вас.

Например, «инъекция почтовых заголовков» напрямую касается формы на сайте-визитке. Слабо защищённую форму используют как источник спама и портят репутацию домена компании — будут ли письма доходить до адресата. Когда письма с формы перестают доходить, это сразу потеря обращений; разбор причин — в статье «Почему не доходят письма с формы обратной связи».

4. «Устранение причины» и «компенсирующие меры» — как думать о защите

Сильная сторона этого документа в том, что меры разделены на два вида.

• Устранение причины: реализация, которая убирает саму причину уязвимости. Для SQL-инъекции, например, собирать SQL-запрос не конкатенацией строк, а плейсхолдерами
• Компенсирующие меры: снижают шанс успешной атаки и размер ущерба, если уязвимость всё же осталась. Например, не показывать текст ошибки в браузере как есть

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

5. Как пользоваться документом при заказе и приёмке

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

• На этапе оценки стоимости и требований: в техническое задание или RFP добавить одну фразу — «реализовать меры против уязвимостей, которые перечисляет документ IPA „Как создать безопасный веб-сайт“». Когда критерий назван, требование яснее расплывчатого «учесть безопасность»
• На этапе приёмки: запросить результаты проверки по соответствующим пунктам чек-листа реализации защиты
• На этапе договора: письменно разграничить, кто после публикации обновляет CMS, плагины и сервер, и входит ли реакция на найденную уязвимость в договор на сопровождение или это отдельная оценка

Третий пункт особенно важен. Безопасность сайта не «готова» в день сдачи: её держат тем, что следят за новыми уязвимостями после публикации. Вопрос «кто продолжает этим заниматься» — та же конструкция, что и граница сопровождения в статье о договорах на заказную разработку и сопровождение.

5.1. Пример формулировок для ТЗ и RFP

Фраза «учесть безопасность» не говорит, по чему считать требование выполненным. Если назвать документ и сдаваемые материалы, требование можно проверить. Например, так:

Требования к безопасности

1. Веб-приложение по этому заказу должно реализовать меры, которые в главе 1 документа IPA «Как создать безопасный веб-сайт, 7-я пересмотренная редакция» отнесены к «устранению причины», по каждой перечисленной там уязвимости.
2. При сдаче представить результаты самопроверки по всем пунктам прилагаемого «Чек-листа реализации защиты». Если пункт помечен как «не требуется», рядом указать причину (например, такой функции в системе нет).
3. Для экранов с динамической обработкой (форма обратной связи, поиск, вход, скачивание файлов и т. п.) в проектной документации описать, как обрабатывается ввод и как выполняется экранирование при выводе.
4. В договоре на сопровождение указать, кто и как часто обновляет ядро CMS, тему, плагины и среду выполнения после публикации, а также срок реакции и порядок оплаты, если обнародована критическая уязвимость.

Все четыре пункта с самого начала вставлять не обязательно. Для сайта в основном «о компании» достаточно 1 и 2 — и разговор на приёмке уже совсем другой, чем при заказе по принципу «безопасность на вашей стороне».

5.2. Что внутри чек-листа

Чек-лист — один файл Excel: 47 пунктов реализации по главе 1 «Как создать безопасный веб-сайт, 7-я пересмотренная редакция», разложенных по 11 видам уязвимостей. В каждой строке: вид уязвимости, характер меры (устранение причины / компенсирующие меры), поля отметки (сделано / не сделано / не требуется), формулировка пункта и номер пояснения в основном тексте.

Сами пункты сформулированы, например, так:

(формулировки пунктов — цитаты из чек-листа реализации защиты, прилагаемого к IPA «Как создать безопасный веб-сайт, 7-я пересмотренная редакция»)

Заказчику удобно, что в чек-листе есть отметка «не требуется». На сайте без входа пустые пункты про управление сессией — нормально. Но без записи не отличить «функции нет, поэтому не требуется» от «просто пропустили». Если «не требуется» написано вместе с причиной, разговор на приёмке становится конкретным.

6. Работающий сайт стоит «диагностировать»

Для уже опубликованного сайта полезно отдельное приложение «Спецификация диагностики веб-сайта». Это спецификация пунктов проверки безопасности работающего сайта (13 пунктов); по ней же можно ориентироваться, что должно входить в услугу проверки на уязвимости.

На корпоративном сайте малого и среднего бизнеса на практике риск особенно часто собирается в двух местах:

• Места, которые принимают ввод: форма обратной связи, строка поиска, вход в личный кабинет и т. п. С ними связана большая часть уязвимостей из главы 1
• Эксплуатация CMS: сайт, на котором остановились обновления ядра, темы или плагинов CMS вроде WordPress, — типичный сценарий, когда известную слабость используют, чтобы подменить содержимое. Очень часто так и не решено, чья это работа, и сайт просто оставляют как есть

Если нагрузку по обновлению CMS хочется пересмотреть вместе со всей схемой эксплуатации, полезна и статья о миграции с WordPress. Есть и проектное решение уменьшить саму поверхность атаки: сократить динамическую обработку и уйти в статическую структуру сайта. То, что при создании сайтов мы берём статическую структуру на основе дизайн-системы Цифрового агентства Японии, — продолжение той же логики.

Отметим, что безопасная эксплуатация веб-сайта также стоит пунктом самопроверки в редакции 4.0 «Руководства по информационной безопасности для малого и среднего бизнеса» IPA. Где это место в защите компании в целом — в статье о редакции 4.0 руководства.

7. Краткий словарь терминов

Ниже — слова из этой статьи, которые всплывают на встречах со студией. Если смысл каждого можно сказать одной строкой, при объяснении вы сами отличите, речь об устранении причины или о компенсирующих мерах.

Итог

Соберём главное из документа IPA «Как создать безопасный веб-сайт».

• Стандартный справочник (7-я пересмотренная редакция, 115 страниц) по 11 видам слабых мест сайта и мерам против них, построенный на уведомлениях об уязвимостях, которые реально поступали в IPA
• Меры идут в два слоя: устранение причины и компенсирующие меры. Компенсирующие меры вроде WAF не заменяют устранение причины
• Заказчик может назвать документ в требованиях, принять работу по чек-листу и в договоре зафиксировать, кто обновляет сайт после публикации
• Уже работающий сайт стоит периодически проверять, ориентируясь на «Спецификацию диагностики веб-сайта»
• Реальный риск корпоративного сайта чаще всего собирается в обработке ввода (формы и подобное) и в заброшенной CMS

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

Если вы планируете создать или обновить сайт

При создании и обновлении сайтов KomuraSoft предлагает решения в логике этой статьи: реализацию форм, статическую структуру, которая не опирается на CMS сильнее, чем нужно, и схему обновлений после публикации. Можно начать и с разбора текущего состояния — если пока непонятно, в каком виде ваш сайт сейчас.

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что за документ «Как создать безопасный веб-сайт»?

Это материалы по безопасности для разработчиков и операторов веб-сайтов, которые публикует IPA (Information-technology Promotion Agency, Япония). Среди сведений об уязвимостях, поступивших в IPA, документ берёт те, по которым уведомлений было больше, и те, чей ущерб при атаке выше, и разбирает угрозы и меры. Актуальная 7-я пересмотренная редакция опубликована в марте 2021 года, объём — 115 страниц. Помимо основного текста бесплатно доступны чек-лист реализации защиты и отдельные приложения «Как безопасно вызывать SQL» и «Спецификация диагностики веб-сайта».

Нужна ли защита даже сайту уровня «о компании»?

Нужна. Если есть форма обратной связи, уже работает программа, которая обрабатывает ввод. Если стоит CMS вроде WordPress, под ударом и панель администратора, и плагины. Злоумышленники не обязательно выбирают жертву по размеру компании: они автоматически находят уязвимые сайты и используют их для подмены содержимого, раздачи вирусов или как источник спама. Опасность сайта в том, что вы одновременно оказываетесь и пострадавшей стороной, и источником вреда для контрагентов и посетителей.

Чем устранение причины отличается от компенсирующих мер?

В «Как создать безопасный веб-сайт» меры разделены на два вида. Устранение причины — способ реализации, который убирает саму причину уязвимости (например, собирать SQL-запрос через плейсхолдеры). Компенсирующие меры снижают шанс успешной атаки и размер ущерба, если уязвимость всё же осталась (например, не показывать текст ошибки в браузере как есть). Одни компенсирующие меры причину не убирают, поэтому правильный порядок такой: сначала устранение причины, компенсирующие меры — поверх него.

Что проверить по безопасности, когда заказываете сайт у студии?

На этапе оценки стоимости стоит как минимум уточнить три вещи: 1) реализованы ли меры против уязвимостей из «Как создать безопасный веб-сайт», 2) может ли исполнитель показать результаты проверки — например, по прилагаемому чек-листу реализации защиты, 3) кто после публикации будет обновлять CMS и плагины (входит ли это в договор на эксплуатацию и сопровождение). Требования по безопасности дорого добавлять потом, поэтому их лучше закрепить письменно до заключения договора.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.