Content Security Policy

CSP — механизм защиты веб-приложений в браузере, который регулирует из каких источников браузер может загружать ресурсы и выполнять их (скрипты, стили, шрифты, картинки и т.д.)

Основная задача CSP — защитить пользователя от инъекционных атак, типа XSS, блокируя любые недоверенные ресурсы

CSP можно задавать через HTTP заголовок или через meta тег. И, если честно, с CSP в мета тегах я никогда не сталкивался, поэтому осознанно опущу эту часть, такой способ задания наименее гибкий и полезный и подходит только для статики

Обычно политику можно задать в конфиге Nginx, условного Express или даже в докере через заголовок: Content-Security-Policy. Выглядеть это в упрощённом случае может примерно так:

Content-Security-Policy: default-src 'self' https://trusted.ru;

Эта запись означает, что ресурсы можно загружать только с домена приложения либо с trusted.ru

Если на сайте настроена CSP без разрешения на инлайн-скрипты 'unsafe-inline' и без сторонних доменов, код злоумышленника просто не выполнится: браузер заблокирует <script> вне белого списка. Это эффективно снижает риск XSS

unsafe-inline — это директива CSP, которая позволяет браузеру выполнять инлайн-скрипты, вставленные в дом на лету. Это может быть удобно, но сильно ослабляет защиту сайта в целом.

Вот так это может выглядеть:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline';

В целом, если не заниматься какой-то откровенной порнографией, то современные инструменты разработки типа Nuxt/Next из коробки несут в себе очень много минорных и не очень фичей для безопасности ваших пользователей, не отключайте их, если не знаете, что делаете

Ну и так же помните, что фреймворки не защищают вас полностью

А CSP — не панацея, но очень мощный инструмент “защиты в глубину”.
Настройте хотя бы простое правило (default-src 'self'), а дальше постепенно добавляйте всё, что вам будет нужно. Это всё равно лучше, чем ничего

Спасибо за прочтение, это важно для меня 🥰

@prog_way_blog — чат — #theory #useful #web

Ещё один пример XSS уязвимости

Предположим, сайт a.com не защищён от XSS. Допустим, там есть URL-параметр, который встраивается в страницу как есть:

<div>Результаты поиска: <?php echo $_GET['query']; ?></div>

Что делает злоумышленник:

1. Создаёт специальную ссылку, например:

https://a.com/search?query=<script>alert('Я украл твою почку!')</script>

2. Обманом заставляет вас перейти по этой ссылке (через фишинговое письмо, сообщение в соцсети и т.д.)

Что происходит у вас в браузере:

1. Вы заходите на a.com через эту ссылку

2. Сервер a.com вставляет <script>...</script> прямо в HTML

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

Ну и всё, вы остались без почки

Поможет ли тут CSP? Ответ: увы, нет

Нужно понимать, что CSP проверяет только источник, а не содержимое скрипта. Тут вредоносный скрипт встроил сам доверенный сервер, CSP такой скрипт ничем не смутит. Зато эту проблему можно решить банальным экранированием

Спасибо за прочтение, это важно для меня 💖

@prog_way_blog — чат — #theory #useful #web

Сам себе режиссёр?

Сегодня принято считать, что FrontOps — это попытка соединить посредственного DevOps-инженера и фронтендера в одном лице. Но, как по мне — это наглядная демонстрация T-shape подхода в оценке разработчиков

T-shape — это модель компетенций, где обычно выделяют одну доминанту (например, фронтенд) и множество навыков рядом с основным (для фронтендера, например — CI/CD, DevOps, UI/UX и тд)

Также к навыкам рядом можно относить и soft skills, например навык управления командой и прочее

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

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

Для кандидата выгода очевидна:
— зачастую выше зарплата
— конкурентное положение на рынке
— больше возможностей для развития внутри основной компетенции за счёт заимствования (очень много что в современном фронтенде взято из бекенда, например)

Для компании, в целом, тоже:
— человек «швейцарский нож», который способен закрывать большой пул задач без увеличения штата и зарплатного фонда (один крутой разраб всегда дешевле двух хороших)
— быстрее протекают кросс-процессы

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

➡️ Ситуация первая, печальная
Для деплоя по хорошему нужно бы настроить CI/CD. Если фронтендер не может сделать это сам, на проект будет выделен отдельный DevOps (или FrontOps)

Очень часто наблюдается ситуация, в которой DevOps-ов не хватает, а на мелких проектах держать отдельного DevOps в целом не рентабельно. В таких случаях создается общий пул и один девопс может работать сразу на нескольких проектах

В этой ситуации есть риск потенциального простоя

Какие выходы есть их этой ситуации?
1. Экстренно дёрнуть девопса с другого проекта (плохо — негативный импакт)
2. Заставить фронтендера учиться как там что делается (плохо — долго)
3. Поставить задачу на холд и ждать когда девопс до нее доберётся (плохо — долго)

➡️ Ситуация вторая, выгодная
Фронтендер сам накидает себе базовый .gitlab-ci.yml, а с этим реально не каждый человек на рынке может справиться, и задача решится за час-два

Из двух этих карикатур лично мне очевидно какую именно выберет большинство руководителей

Лично моя философия в том, что не существует такой позиции, как FrontOps-инженер

FrontOps — это фронтендер, который что-то как-то умеет в DevOps (в большинстве случаев)

FrontOps — это DevOps, который что-то как-то умеет в фронтенд

Иного я никогда в своей жизни не видел

И воспринимать, как по мне, это нужно именно так. FrontOps не должен быть заменой DevOps, это лишь дополнительная функция

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

FrontOps это больше о:
— хотя бы примитивном CI/CD
— базовом понимании что такое nginx, CDN, кеширование
— умении добавить джобу на прогон юнит тестов без слёз
— умении прочитать логи с кубер пода, логи с sentry, нажать кнопку в кейклоке без панических атак ну и тд

Навык безусловно полезный и который точно нужно качать, но какого-то «рецепта успеха» тут точно нет

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

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

Также советую прочитать статью из блога Игоря Федюкина

Не бомбите, берегите нервы, себя и своих близких. Всех благ❤️

@prog_way_blog — чат

Первый шаг в сторону FrontOps

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

Длительное время любил и уважал Vercel, да и до сих пор считаю, что для базового деплоя проекта «в интернет» ничего лучше Vercel/Netlify для новичка не придумали, но со временем начал сталкиваться со множеством ограничений бесплатной версии. Например, веб-сокеты в бесплатной версии у меня поднять так и не получилось из-за ограничений самого сервиса

Но самое главное — нет контроля над происходящим, а он порой бывает невероятно полезен

Поэтому я начал использовать Coolify — опенсорсной self-hosted альтернативой. Если утрировать и упрощать, то представьте, что вы владелец Vercel. Вот Coolify даёт вам такое чувство, поскольку это коробочное решение, которое можно поднять на своём сервере по очень простому гайду и с удовольствием пользоваться

В Coolify есть множество функций, которые пригодятся каждому:
— импорт репозиториев с GitHub, в том числе приватных
— автоматическая установка SSL сертификатов (только при условии, что используете домен с reg.ru, если не ошибаюсь — такой там вендор-лок)
— редеплой по мержу
— переменные окружения, возможность создавать разные окружения для одного проекта
— возможность управлять сразу множеством серверов для деплоя
— уведомления, работа в команде, своё s3 хранилище и так далее

Ну и что не менее важно — есть готовый набор огромного набора инструментов, начиная Keycloak, Umami и PostgreSQL DBaaS в 2 клика, заканчивая сервером для майнкрафта — вот всё это уже реализовано и отлично работает

Звучит как ужасная продажная реклама, но это, к сожалению, не так. Очень жаль))

Для первого погружения в FrontOps — инструмент шикарный

Можно задеплоить парочку проектов, научиться писать хотя бы Dockerfile, может и пайплайн из парочки джобов собрать, а потом уже двигаться дальше

Прямо сейчас у меня развёрнуто несколько проектов, в том числе зеркало progway, про которое в канале я никогда не упоминал. Это написанная за пару вечеров прила, которая является почти полным аналогом канала. Сделано зеркало просто для того, чтобы привлекать новый трафик в канал с поиска в условном яндексе

Пока этим приложением у меня нет времени заниматься, оно в подвешенном состоянии, но когда нибудь оно будет сиять

Ну а если вы вдруг любитель поиграть в игру «Бункер», такой проект у меня тоже найдётся. Прила ещё достаточно давно была написана чисто для друзей, но не вижу преград не поделиться

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

А для кого-то такие пет-проекты и coolify в целом могут стать первым шагом в изучение темы FrontOps

Не обязательно всё время быть сильными. Иногда достаточно просто жить дальше, держаться за принципы и не давать обстоятельствам нас сломать — и этого уже достаточно🥰

@prog_way_blog — чат — #theory #blog #useful

Шпаргалка с чего начать в FrontOps

➡Для себя любимого

1. Свободно ориентироваться в терминале, уметь выходить из вима и пользоваться ssh
2. Разобраться со сборкой — разобраться как минимум с Vite, понимать как исходный код превращается в бандл
3. Разобраться с Docker — понять зачем вообще он нужен, как оптимизировать Dockerfile

➡Для команды любимой

1. Автоматизировать всё, что можно автоматизировать — изучить prettier, biome, eslint, stylelint — интегрировать в проект и забыть о спорах на ревью о формате кода. Также можно изучить husky и запускать все необходимые проверки ещё до коммита
2. Разобраться с GitLab Actions, именно это используют в большинстве случаев — прогонять линтеры и тесты, собирать превью билд для пул реквестов
3. Изучить мониторинг и аналитику — Sentry для мониторинга и Umami или Matomo для аналитики подойдут для большинства проектов

➡Для пользователя любимой
1. Изучить что такое CDN и как это можно использовать, что такое S3, микрофронтенды, хотя бы базово разбираться в nginx
2. Разобраться с производительностью — рассмотреть и оптимизировать бандл, научиться использовать Lighthouse, react-scan и в целом тестировать свои приложения на слабых устройствах

Гайд не исчерпывающий, но может выступить ориентиром

Если вам что-то не нравится делать — возможно, это навык, который стоит просто прокачать? ❤

@prog_way_blog — чат