Безопасность веб-приложений на базовом уровне: что внедрять уже в первом проекте

Когда разработчик собирает первый веб-проект, вопросы безопасности почти всегда уходят на второй план. Сначала хочется, чтобы всё просто заработало: форма отправлялась, авторизация пускала пользователя в кабинет, данные сохранялись в базу. Это понятный соблазн, но именно на старте формируются инженерные привычки, которые потом напрямую влияют на качество кода, поддержку продукта и стоимость изменений.

На практике безопасность не живёт отдельно от разработки. Она связана с архитектурой приложения, с тем, как вы работаете с входными данными, как проектируете авторизацию, как настраиваете деплой и как поддерживаете зависимости. Если не заложить базовые меры сразу, позже почти неизбежно придётся возвращаться к уже написанному коду, переписывать критичные участки и исправлять решения, которые сначала казались «временными».

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

Почему безопасность важна с самого начала

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

Формирование привычек. Если с первого проекта вы закладываете в код хеширование паролей, проверку входных данных, защиту форм и аккуратную работу с сессиями, это становится нормой. В результате безопасность перестаёт быть отдельным этапом «потом» и становится частью everyday development: как code review, тесты или рефакторинг.

Экономия времени на рефакторинг. Перестроить уже работающую схему аутентификации, заменить небезопасные SQL-запросы или протянуть HTTPS-редиректы по всему окружению заметно сложнее, чем сделать это сразу. Чем дальше проект заходит, тем выше стоимость переделки: больше кода, больше интеграций, больше сценариев, которые можно сломать.

Репутация и доверие. Даже учебный или pet-проект может получить первых пользователей, попасть в портфолио или стать частью собеседования. И если в нём обнаруживается очевидная уязвимость, это говорит не только о проблеме в конкретном коде, но и об уровне инженерного мышления автора.

Понимание принципов. Простые проекты удобны тем, что на них легче понять базовые механизмы: как работают хеши, зачем нужны prepared statements, почему CSRF-защита не заменяется фронтенд-проверками. Эти знания потом масштабируются на более сложные системы — с API, микросервисами, очередями и распределённой авторизацией.

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

Аутентификация: правильно с первого дня

Аутентификация — это проверка, что пользователь действительно тот, за кого себя выдаёт. Ошибки здесь особенно болезненны: если этот слой реализован небрежно, уязвимость затрагивает всё приложение целиком. Поэтому в первом же проекте важно использовать не «самодельные» решения, а проверенные механизмы языка и фреймворка.

Никогда не храните пароли в открытом виде

Это базовое и абсолютно обязательное правило. Если в таблице пользователей в поле password лежит исходный пароль, приложение уже считается скомпрометированным по дизайну. Достаточно утечки базы, дампа окружения или ошибки в доступах — и все учётные данные оказываются раскрыты.

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

Что делать: использовать хеширование паролей. Хеш-функция преобразует пароль в строку фиксированного вида, из которой нельзя восстановить исходное значение. При входе в систему вы не расшифровываете пароль, а вычисляете хеш для введённого значения и сравниваете его с тем, что хранится в базе.

Практически:

Используйте встроенные функции языка или фреймворка. В PHP это password_hash() и password_verify(). В Laravel — Hash::make() и Hash::check(). Не пишите собственный алгоритм хеширования, не используйте md5, sha1 и подобные примитивы для хранения паролей. Это типичная ошибка начинающих проектов и один из самых частых антипаттернов, который потом приходится вычищать в миграциях и логике авторизации.

С точки зрения качества кода это ещё и вопрос поддерживаемости: стандартные механизмы умеют обновлять алгоритмы и параметры безопасности эволюционно, без переписывания всей системы логина. Самодельные решения такой гибкости обычно не дают.

Сессии и токены

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

Сессии означают, что информация об авторизации хранится на сервере. Браузеру отдаётся идентификатор сессии, как правило в cookie, и он отправляется с каждым следующим запросом. Сервер получает этот идентификатор, ищет соответствующую сессию и понимает, какой пользователь сейчас работает.

Токены работают иначе: сервер выдаёт клиенту подписанный токен, в котором уже содержится информация об авторизации, например идентификатор пользователя и срок действия. Клиент передаёт токен с запросами, а сервер проверяет подпись и валидность содержимого.

Для классического веб-приложения, где сервер рендерит HTML, сессии обычно проще, понятнее и безопаснее в повседневной эксплуатации. Для API и SPA токены удобнее, потому что лучше вписываются в отделённый фронтенд и мобильных клиентов. Но здесь важно не поддаться моде: JWT или любые другие токены не делают архитектуру автоматически «современнее». Если приложение можно надёжно и просто вести через серверные сессии, это часто лучший выбор.

Практически для сессий (PHP):

Используйте безопасные cookie-параметры, контролируйте срок жизни сессии, регенерируйте идентификатор после логина и не храните в сессии лишние данные. Чем меньше в ней состояния и чем понятнее жизненный цикл, тем проще сопровождение и диагностика.

Практически для токенов (Laravel API):

Используйте встроенные механизмы фреймворка, а не пишите собственную реализацию подписи, валидации и истечения токенов. В реальной разработке самодельная аутентификация почти всегда создаёт больше рисков, чем пользы. Особенно если в проекте нет зрелого тестового покрытия на сценарии авторизации, ротацию токенов и отзыв доступа.

HTTPS везде

Если приложение доступно по HTTP без шифрования, любые передаваемые данные — логины, пароли, cookie, токены, содержимое форм — можно перехватить. Для пользователя это выглядит как обычный сайт, но фактически весь трафик читается третьими лицами, особенно в общих сетях вроде публичного Wi‑Fi.

Что делать: использовать HTTPS везде. Сегодня это не «опция для продакшена», а базовая норма. Сертификаты можно получить бесплатно через Let’s Encrypt, а большинство облачных платформ включают HTTPS по умолчанию.

Практически:

• Если вы используете облачный хостинг вроде Heroku, Vercel или AWS, HTTPS часто уже настроен или включается в пару шагов.
• Если приложение развёрнуто на собственном сервере, установите сертификат Let’s Encrypt. Обычно на это действительно уходит около 10 минут.
• Проверьте, что все HTTP-запросы редиректятся на HTTPS, а cookie для сессий помечены как Secure.

С инженерной точки зрения HTTPS влияет не только на безопасность передачи данных, но и на предсказуемость поведения приложения. Многие современные браузерные механизмы и API корректно работают только в защищённом контексте. Поэтому HTTPS — это ещё и способ избежать странных багов, которые появляются уже не на уровне угроз, а на уровне платформы.

Защита от SQL-инъекций

SQL-инъекция возникает, когда пользовательский ввод попадает в SQL-запрос как часть исполняемого кода. Это одна из самых известных и при этом до сих пор актуальных уязвимостей, потому что её причина банальна: разработчик смешивает данные и логику запроса.

Пример уязвимости

Если запрос строится через конкатенацию строк, приложение становится уязвимым практически мгновенно. Классический сценарий выглядит так: значение email из формы вставляется прямо в SQL без изоляции параметров.

Если передать email = ' OR '1'='1, запрос изменит свою логику и начнёт возвращать все записи вместо одной. В ещё более опасных вариантах можно попытаться внедрить что-то вроде '; DROP TABLE users; --, чтобы выполнить разрушительную операцию над базой.

На практике последствия зависят от драйвера, конфигурации БД и ограничений на выполнение нескольких выражений, но сам принцип остаётся тем же: если входные данные трактуются как SQL-код, приложение небезопасно.

Защита: подготовленные запросы

Что делать: всегда использовать подготовленные запросы — prepared statements. В этом подходе SQL-шаблон и данные передаются отдельно. База данных заранее понимает структуру запроса, а значения параметров обрабатываются как данные, а не как исполняемый фрагмент SQL.

Практически (PHP с PDO):

Используйте prepare() и привязку параметров. Это не только безопаснее, но и делает код читаемее: структура запроса отделена от пользовательского ввода, что упрощает review и дальнейшее сопровождение.

Практически (Laravel):

Laravel использует prepared statements под капотом. Если вы работаете через Query Builder или Eloquent, защита уже встроена, и ничего отдельно настраивать не нужно.

Правило: если пишете SQL вручную, используйте подготовленные запросы. Если используете ORM вроде Eloquent в Laravel или Doctrine в Symfony, базовая защита от SQL-инъекций уже есть.

Здесь есть важный инженерный нюанс: ORM снижает риск, но не отменяет необходимости думать. Как только разработчик начинает собирать фрагменты raw SQL вручную, динамически формировать ORDER BY, имена колонок или условия из непроверенных данных, защита фреймворка перестаёт быть достаточной. Поэтому хорошая практика — не только «доверять ORM», но и минимизировать участки, где raw SQL вообще появляется в кодовой базе.

CSRF-защита: простая, но критичная

CSRF (Cross-Site Request Forgery) — это атака, при которой злоумышленник заставляет браузер пользователя выполнить запрос к вашему приложению от имени уже авторизованного пользователя. Снаружи это выглядит как обычный запрос, потому что браузер автоматически подставляет сессионные cookie.

Пример атаки

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

Браузер честно приложит cookie сессии, сервер увидит авторизованного пользователя и выполнит действие. То есть атака не взламывает логин напрямую — она использует доверие между браузером и вашим приложением.

Защита: CSRF-токены

Что делать: использовать CSRF-токены во всех формах и state-changing запросах. Сервер генерирует уникальный токен, встраивает его в форму, а затем проверяет при отправке. Вредоносный сайт не может прочитать этот токен и подставить его корректно, поэтому поддельный запрос будет отклонён.

Практически (PHP):

Токен обычно хранят в сессии и вставляют в скрытое поле формы. На сервере сравнивают значение из запроса с тем, что сохранено в сессии. Логика несложная, но реализовывать её вручную стоит аккуратно: ошибки в именах полей, повторное использование токенов или пропуск проверки на отдельных маршрутах быстро создают дыры в защите.

Практически (Laravel):

В Laravel CSRF-защита встроена, и в обычных сценариях достаточно добавить @csrf в форму и не отключать middleware без необходимости.

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

Валидация и санитизация входных данных

Это одна из самых недооценённых тем среди начинающих разработчиков. Многие воспринимают валидацию как косметику для форм, хотя на деле это фундаментальная часть безопасности и общей надёжности приложения. Базовое правило здесь простое: никаким входным данным доверять нельзя.

Валидация

Валидация отвечает на вопрос: данные вообще похожи на то, что мы ожидаем? Email должен быть email, возраст — числом в допустимом диапазоне, пароль — иметь минимальную длину, enum-поле — содержать одно из разрешённых значений.

Практически:

Проверяйте тип, формат, длину, обязательность, диапазон значений и бизнес-ограничения. И делайте это на сервере, независимо от того, есть ли клиентская проверка в JavaScript.

Практически (Laravel):

Используйте встроенные валидаторы и form request’ы. Это даёт сразу несколько преимуществ: правила собраны в одном месте, их проще тестировать, а контроллеры не захламляются одноразовой логикой. С точки зрения поддерживаемости это намного лучше, чем разрозненные if по всему приложению.

Санитизация

Санитизация — это очистка данных или их приведение к безопасному виду. Например, если в поле имени прилетает <script>alert('xss')</script>, приложение должно либо удалить опасные конструкции, либо гарантировать безопасный вывод этих данных.

Практически:

Удаляйте или нормализуйте лишние символы там, где это действительно нужно: например, обрезайте пробелы, убирайте неожиданные HTML-теги, приводите строки к ожидаемому формату. Но здесь важен баланс. Слишком агрессивная санитизация на этапе сохранения может испортить данные и затруднить дальнейшую обработку.

Правило: валидируйте на сервере, не на клиенте. Клиентская валидация полезна для UX, но не имеет отношения к доверию. Любой запрос можно отправить в обход интерфейса — через curl, Postman, DevTools или произвольный скрипт.

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

XSS: защита от внедрения кода

XSS (Cross-Site Scripting) — это уязвимость, при которой злоумышленник внедряет в приложение JavaScript-код, а затем этот код выполняется в браузере других пользователей. В результате можно украсть сессию, подменить интерфейс, выполнить действия от имени пользователя или встроить вредоносный клиентский сценарий.

Пример уязвимости

Представьте, что в приложении есть комментарии, и текст комментария выводится на страницу как есть, без экранирования. Тогда злоумышленник может сохранить в комментарии не текст, а HTML/JavaScript, например тег script.

Когда другой пользователь откроет страницу, браузер воспримет этот фрагмент не как данные, а как исполняемый код. Именно поэтому XSS особенно опасен: он бьёт уже не по серверу, а по пользователям приложения.

Защита: экранирование

Что делать: экранировать пользовательские данные перед выводом в HTML. То есть преобразовывать специальные символы в безопасные сущности, чтобы браузер показывал их как текст, а не выполнял как код.

В PHP для этого используется htmlspecialchars(). Она превращает < в <, > в > и так далее. В результате даже если пользователь прислал потенциально опасный HTML, он будет отображён как обычная строка.

Практически (Laravel с Blade):

В Blade конструкция {{ }} экранирует данные по умолчанию. Конструкция {!! !!} не экранирует ничего, и использовать её стоит только тогда, когда источник данных полностью контролируем и вы точно понимаете, зачем это нужно.

Правило: если выводите данные, введённые пользователем, экранируйте их.

Из практического опыта: XSS часто появляется не в очевидных местах вроде комментариев, а в административных панелях, полях описаний, markdown-рендерах, логах, сообщениях об ошибках и пользовательских настройках профиля. Поэтому полезно думать не категориями «форма комментария опасна», а категориями trust boundary: всё, что пришло извне, по умолчанию должно считаться недоверенным.

Управление зависимостями и обновления

Даже если ваш собственный код написан аккуратно, приложение всё равно зависит от внешних библиотек, пакетов и фреймворков. А значит, уязвимости могут появиться не у вас напрямую, а в том, что вы подключили через Composer, npm или другой пакетный менеджер.

Как это работает

Практически (PHP с Composer):

Проверяйте дерево зависимостей на известные уязвимости и обновляйте пакеты до безопасных версий. Не откладывайте это на месяцы: чем дольше проект живёт без регулярных обновлений, тем болезненнее потом миграция.

Практически (Node.js с npm):

Используйте стандартные инструменты аудита и отслеживания advisories. Но относитесь к автоматическим рекомендациям с головой: не каждое обновление стоит накатывать без проверки. Сначала смотрят changelog, затем прогоняют тесты, потом уже деплоят.

Правило: регулярно обновляйте зависимости. Минимум — раз в месяц проверяйте обновления безопасности.

Если вы используете GitHub, можно включить Dependabot — он будет автоматически создавать pull request’ы с обновлениями. Это хороший рабочий компромисс: команда видит изменения явно, обсуждает их в code review и не забывает о безопасности.

Важно понимать, что управление зависимостями — это не только «поднять версии». Это часть процесса сопровождения. Хорошая практика — фиксировать версии, держать воспроизводимые сборки, прогонять тесты в CI и не тащить в проект лишние библиотеки. Чем меньше внешних пакетов, тем меньше поверхность атаки и тем проще поддержка.

Логирование и мониторинг

Даже если базовые меры безопасности настроены правильно, этого недостаточно без наблюдаемости. Любая защита ценнее, когда вы можете увидеть, что происходит в системе: кто пытался войти, какие ошибки возникали, какие действия выполнялись и где поведение отклоняется от нормы.

Что логировать

• Попытки входа: успешные и неудачные. Это помогает замечать перебор паролей, атаки на аккаунты и проблемы у пользователей с авторизацией.
• Критические действия: смена пароля, удаление данных, изменение прав доступа, обновление email и другие чувствительные операции.
• Ошибки: исключения, ошибки БД, неожиданные состояния, сбои интеграций.
• Подозрительная активность: большое число запросов с одного IP, аномальная частота действий, нехарактерные маршруты.

Практически (PHP):

Минимальный вариант — писать события в лог-файл. Но лог должен быть структурированным и достаточно информативным: что произошло, когда, с каким пользователем, на каком маршруте и с каким результатом. Бессмысленные строки вида «error happened» для расследования почти бесполезны.

Практически (Laravel):

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

Логи нужно не только сохранять, но и анализировать. Для небольшого проекта достаточно файлов на сервере. Для более серьёзного приложения удобно использовать Sentry, ELK Stack или аналогичные инструменты. Они упрощают агрегацию, поиск по событиям, алерты и анализ проблем после релиза.

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

Таблица практик по уровню приоритета

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

Контрольный список для первого проекта

Используйте этот список как минимальный baseline перед релизом, публикацией pet-проекта или передачей кода на review:

• [ ] Пароли хешируются функцией password_hash() или эквивалентом
• [ ] Все SQL-запросы используют подготовленные запросы
• [ ] Приложение работает по HTTPS
• [ ] Формы защищены CSRF-токенами
• [ ] Входные данные валидируются на сервере
• [ ] Пользовательские данные экранируются перед выводом в HTML
• [ ] Сессии/токены используются правильно
• [ ] Зависимости регулярно проверяются на уязвимости
• [ ] Логируются попытки входа и критические действия
• [ ] Нет хардкода секретов (API-ключей, паролей) в коде

Последний пункт особенно важен и часто забывается в первых проектах. Секреты должны храниться в переменных окружения, менеджерах секретов или конфигурации, исключённой из репозитория. Хардкод токенов и паролей — это одновременно проблема безопасности, деплоя и переносимости окружений.

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

«У меня же только учебный проект, зачем мне безопасность?»

Это примерно как учиться писать production-код без тестов и code review в надежде «потом научиться правильно». Так не работает. Базовые привычки формируются именно в учебных и небольших проектах. Если сейчас игнорировать защиту, позже это будет проявляться уже в коммерческой разработке — только цена ошибки станет выше.

«Я буду добавлять безопасность потом, когда проект станет популярным.»

Обычно «потом» означает дорогостоящий рефакторинг. К этому моменту уже есть база пользователей, слой авторизации, интеграции, фронтенд-форма, возможно, API-клиенты. Любое исправление затрагивает больше кода и требует более аккуратного деплоя. И да, если приложение взломают до того, как вы решите «заняться безопасностью», ущерб для репутации уже не откатить.

«Я использую фреймворк, он позаботится о безопасности.»

Фреймворк действительно сильно помогает, но не принимает решения за разработчика. Laravel может экранировать данные в Blade и защищать формы от CSRF, но если вы используете {!! !!}, отключаете middleware или вставляете raw SQL из пользовательского ввода, уязвимость создаёте вы, а не фреймворк.

«Я буду использовать шифрование для всего.»

Шифрование полезно, но оно не заменяет правильную бизнес-логику. Оно защищает данные при передаче и хранении, но не спасёт, если вы неверно проверяете права доступа, выдаёте токен с лишними привилегиями или разрешаете опасное действие без повторной проверки пользователя. В безопасности почти всегда важнее корректная модель доступа и аккуратная обработка данных, чем абстрактное желание «зашифровать всё».

FAQ

Вопрос: Нужно ли мне изучать криптографию?

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

Вопрос: Что делать, если я обнаружил уязвимость в своём приложении?

Ответ: Сначала устранить проблему и воспроизвести сценарий в контролируемых условиях, чтобы убедиться, что исправление действительно работает. Затем посмотреть логи и понять, могла ли уязвимость использоваться ранее. Если приложением пользуются другие люди, их нужно уведомить. Для серьёзных случаев имеет смысл подготовить security advisory или хотя бы внутреннее описание инцидента, чтобы команда не повторила ту же ошибку в будущем.

Вопрос: Как часто нужно обновлять зависимости?

Ответ: Проверяйте еженедельно. Критические security-обновления ставьте как можно быстрее, остальные — обычно раз в месяц. Перед обновлением запускайте тесты, а если проект серьёзнее pet-проекта — прогоняйте изменения через CI и staging. Само обновление без проверки — это не инженерная практика, а игра в удачу.

Вопрос: Нужна ли мне двухфакторная аутентификация (2FA)?

Ответ: Для первого проекта обычно нет. Это дополнительная сложность в UX, в реализации и в поддержке. Но если в приложении появятся чувствительные операции — платежи, управление доступами, удаление данных, админ-функции, — 2FA стоит рассмотреть на следующем этапе развития продукта.

Вопрос: Что делать с данными пользователей, которые я больше не использую?

Ответ: Удалять. Это принцип data minimization: собирать только то, что реально нужно, и не хранить лишнее дольше необходимого. Чем меньше чувствительных данных лежит в системе, тем меньше риск утечки и тем проще соблюдение требований к приватности. С точки зрения архитектуры это ещё и уменьшает объём данных, которые нужно защищать, мигрировать и обслуживать.

Вопрос: Я вижу в коде eval() или exec(). Это опасно?

Ответ: Да, это тревожный сигнал. Такие функции исполняют код или системные команды из строки. Если в эту строку попадают пользовательские данные, риск уязвимости становится очень высоким. В большинстве веб-приложений это плохой дизайн. Если кажется, что без eval() не обойтись, скорее всего задачу нужно решать иначе — через нормальную архитектуру, шаблоны, конфигурацию или безопасные API.

Заключение

Безопасность веб-приложения на базовом уровне — это не отдельный большой подпроект и не история «для зрелой команды потом». Это набор простых инженерных решений, которые должны появляться в коде с самого начала: хеширование паролей, prepared statements, CSRF-защита, серверная валидация, экранирование вывода, обновление зависимостей и нормальное логирование.

На практике эти меры действительно занимают примерно 10–15% времени разработки, но предотвращают подавляющее большинство типовых проблем. И что ещё важнее, они улучшают не только безопасность, но и качество кода: делают поведение приложения предсказуемее, снижают связанность, упрощают review, облегчают сопровождение и уменьшают стоимость будущих изменений.

Когда вы позже перейдёте к более сложным темам — аудиту безопасности, penetration testing, управлению ключами, rate limiting, защите API, политике доступа и безопасному CI/CD, — у вас уже будет правильная база. Но даже без продвинутых техник описанного в этой статье достаточно, чтобы закрыть большинство распространённых рисков в первом проекте.

Лучший способ начать — не пытаться внедрить всё идеально за один вечер. Возьмите контрольный список, проверьте свой текущий проект и добавляйте практики по одной. Очень быстро это перестанет восприниматься как «дополнительная нагрузка» и станет обычной частью разработки — как тесты, линтер и аккуратный деплой.

Автор: Андрей Ковалёв, разработчик и технический редактор SkilledBird. Несколько лет разрабатывал веб-приложения на PHP и Node.js, участвовал в коммерческих проектах и видел, к чему приводит игнорирование базовых практик безопасности. Сейчас помогает разработчикам строить устойчивые приложения с правильным фундаментом с самого начала.