Браузер на страже api-запросов: строим безопасное общение фронтенда с бэкендом

HTTP

Бэкэнд и фронтенд должны использовать соответствующие HTTP статусы (в определенной степени). Надеюсь, ваш бэкэнд не воспринимает каждую ошибку как 400.

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

Не парсите сообщения об ошибках, чтобы определить, то что авторизация не удалась, код ошибки 401 подходит для этого больше.

Не повторяйте тот же самый запрос, если вы получили 400-ый код потому что он, вероятно, не будет работать снова. А к примеру 500-ый код может означать, что сервер просто перезагружается и повторная попытка будет успешной.

Другие свойства HTTP запросов которые желательно знать:

• HTTP запросы могут быть закрыты сервером если они занимаются слишком много времени прежде чем завершатся. Если вы думаете что некоторая задача займет больше времени чем лимит на запрос (как правило около 20 секунд), вам следует выбрать вместо единичного запрос-ответа, запрос с последующим опросом результата. Или воспользоваться другими механизмами, например веб-сокетами.
• Если вы отправляете большое количество данных на сервер(например видео), вы должны использовать составной HTTP запрос(multipart/form-data), который делит данные на части перед отправкой.
• Иногда неожиданно возникает то, что существует ограничение размера URL. Некоторые веб-интерфейсы передают данные обратно на сервер с query параметрами, но если они длиннее 2048 символов, вам придется изменить такой способ на передачу параметров в теле HTTP запроса.

Делегирование бизнес логики

Если какая-то бизнес логика вашего функционала может быть реализована и на бэкенде и на фронтенде, где лучше её реализовать?

В основном лучше делать это на бекенде. Причины:

1. Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
2. Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
3. Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для pro пользователей. Если ограничение будет сделано на фронтенде, то кто-либо потенциально может провести реверс-инжиниринг и получить доступ к функционалу.

Важные личные качества

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

Про общение клиентов и серверов, или Как это работает на языке компьютера

Есть несколько клиентов. Клиентами могут быть обычные браузеры на компьютере или мобильном устройстве. Один из клиентов — браузер вашего компьютера. Вы хотите получить информацию из интернета. Делаете запрос: вводите ваш вопрос в поисковик Yandex или Google. Сразу же открывается страница с необходимой вам информацией.

Как это работает на самом деле? Ваш клиент, он же браузер, отправляет запрос на сервер. Сначала на сервер пользователя — frontend. Frontend-сервер (компьютер) обрабатывает запрос, выбирает backend-сервер, который в данный момент свободен, и отправляет ему запрос из браузера. Backend-сервер обрабатывает запрос, обращается к базе данных и посылает ответ на запрос обратно frontend-серверу. А frontend, так как он отвечает за удобство пользователя, уже отображает ответ на запрос в виде HTML-страницы.

Передача данных

Веб-безопасность

Знаете, что такое OWASP? Это открытый проект, собирающий статистику и направленный на обеспечение безопасности веб-приложений

Чтобы стать фронтенд-разработчиком в 2021 году, нужно уделять особое внимание безопасности. Хоть способов обезопасить себя и становится больше, но злоумышленники тоже не стоят на месте

Интенсив «Профессия Data Scientist: учимся обработке и анализу данных за 3 дня»

26–28 апреля, Онлайн, Беcплатно

tproger.ru

События и курсы на tproger.ru

Итак, вам нужно понимать преимущества HTTPS перед HTTP, принцип работы CORS, политику защиты контента (CSP), а также регулярно следить за обновлениями на сайте OWASP.

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

День Из Жизни Бэкенд Разработчика

Теперь, давайте решим спор “front end vs. back end”, взглянув на него с другой стороны. Ваш день начинается почти так же, и вы отправляетесь на встречу с техническим директором вашей компании.

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

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

Во время ланча вы слышите о смене дизайна сайта

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

Лучшие книги и средства обучения

• Базовая книга по вашему языку программирования — мне нравятся издания O’Reilly, многие переведены издательством «Питер». 
• Аналогично базовые книги по вашему стеку. 
• Кукбуки (cookbook) по языкам и рекомендации корпораций, статьи в блогах и т.д.
• Бек Кент, Экстремальное программирование. Разработка через тестирование — отличная книга для любого разработчика в принципе, но особенно для бэкендера. Проникнуться философией TDD дорого стоит.
• Джоэл Х. Спольски — можно читать его блог, можно ещё на просторах Рунета найти электронную книгу «Джоэл о программировании» — сборник постов из блога на русском.
• Роберт Мартин «Идеальный программист», «Чистый код» — переводная книга от «Питера» хороша, но в оригинале стиль и шутки вообще бесподобны.
• Мартин Фаулер и коллектив авторов «Шаблоны корпоративных приложений» — «взрослая» книга для джавистов, но не помешает ни для одного серверного языка как сборник инсайтов и крутых находок.
• Бесплатные курсы и видео, которых бесконечно много на Youtube на русском и английском языках. Просто слушайте, повторяйте, систематизируйте знания. Для начала подойдут любые, очень скоро вы научитесь отличать крутые вещи от дилетантских. 
• webref.ru — очень классный сайт для разработчиков веба, разбирайтесь, обучайтесь. 
• codecademy.com — интерактивный сайт для обучения разработке на разных языках программирования на английском, с самого низкого, нулевого, уровня. 
• ITc | сообщество программистов — вагон организованной информации с курсами, лекциями и чем угодно. Читайте комментарии, легко определяйте лучшее для обучения.
• Библиотека программиста — куча книг по любой айти-тематике.

Базис

Начнём с главного — с ОС. Хороший бэкендер должен быть знаком с unix-подобной операционной системой. Это могут быть не только разные Linux-дистрибутивы, но и macOS или FreeBSD, но общепринятым стандартом всё же является Linux. Работать вы можете на ПК или ноутбуке с любой ОС, но Linux нужно знать. Ведь вам придётся довольно активно взаимодействовать с серверами, а большая часть из них работает на Linux.

Интенсив «Профессия Data Scientist: учимся обработке и анализу данных за 3 дня»

26–28 апреля, Онлайн, Беcплатно

tproger.ru

События и курсы на tproger.ru

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

Следующее требование ― знание систем контроля версий. И тут уже без особых альтернатив: нужен именно Git, несмотря на наличие выбора. Изучите сам Git и механику взаимодействия с ветками, если собираетесь работать в команде. Впрочем, если вы интересуетесь бэкенд-разработкой и сейчас читаете этот текст, аккаунт на GitHub у вас уже наверняка есть (а если нет, вы знаете, что делать).

Очень пригодится базовое знание принципа работы Сети в целом. Мы сейчас не говорим о доскональном изучении HTTP и всех тонкостей DNS, но вы должны представлять, что именно происходит при попытке зайти на какой-то сайт. Что к чему подключается, какие работают связки, что грузится в первую очередь и тащит за собой остальное.

Дополнительным преимуществом для начинающего бэкенд-разработчика будет знание хотя бы одного веб-фреймворка — для Python это Django или Flask. Плюс базовые знания SQL

Никто не будет выставлять вас на ежемесячные соревнования SQL-программистов, но важно уметь самому проектировать БД, работать с ними через ORM, если мы говорим про Django, или через SQLAlchemy в случае с Flask

Ну и, конечно, никуда без основ администрирования сервера, хотя бы на уровне «Я могу сам задеплоить свой проект по SSH, не отвлекая коллег от чтения Хабра».

В путь!

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

Изучите основы вёрстки — HTML, CSS. Хватит только основ — остальное наработается в процессе решения задач. Сразу для работы поставьте себе редактор VS Code

Отдельное внимание уделите навыкам работы с Flexbox и CSS grid.
Изучите Bootstrap или bulma.io. Попробуйте создать каркас простого сайта с их помощью; изучите их исходники, они дадут вам хорошее понимание правильной архитектуры проекта

Примерно уже здесь, а лучше как можно раньше, пробуйте собирать какие-нибудь проектики, решать какие-нибудь задачки, нарабатывайте практику.
Изучите JavaScript. Да, тут тоже хватит только основ. Пробегитесь по синтаксису ES6, чтобы примерно его понимать. Попробуйте разобрать, как реализованы те или иные UI-компоненты в вышеупомянутых CSS-фреймворках.
Изучите основы Git. Это система контроля версий, и она уже на данном этапе хорошо вам послужит, позволит фиксировать поэтапно изменения в коде и хранить их.
Изучите BEM/SuitCSS, что больше понравится.
Поймите синтаксис Stylus и Pug.
Начните изучать документацию к Vue.js. Она предельно понятна и на русском языке. В процессе изучения вы узнаете множество смежных вещей — компонентная архитектура, сборка с помощью webpack, работа с API, SSR, flux, автотестирование.
Пробегитесь по библиотеке lodash — она вам очень поможет при написании кода на JavaScript, для более лаконичного кода без велосипедов.
Изучите автотестирование фронтенда. Это важный пункт, если вы сразу его освоите, облегчите себе дальнейшую жизнь. Не откладывайте его на потом. Рекомендую такие инструменты, как Jest и TestCafe. В Vue.js есть хороший инструментарий для автотестов из коробки.
Создайте собственное приложение, используя полученные знания. Придумайте идею или возьмите ту, что у вас давно сидит в голове; не просто так вы ведь решили стать программистом! В дополнение изучите транслируемые в JavaScript языки — TypeScript, CoffeeScript.

Готово! Дальше только практика, вернее, она должна была начаться с первого пункта, а сейчас достигнуть своего апогея. Теперь вы мастер фронтенда! Хотя кто знает, может, к тому времени опять выйдет в свет какой-нибудь инструмент, который всё перевернёт во фронтенде, и придётся полностью менять свои понимания?

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

Первые сайты

Вначале люди писали на чистом HTML, рисовали внешний вид на чистом CSS, делали логику на чистом JavaScript. Типичное старомодное приложение — это когда серверная логика генерирует HTML (отвечая на запрос посетителя, сервер берёт данные из базы данных и вставляет их в HTML) и отдаёт его вместе со статическими файлами стилей и клиентской логики на JavaScript, которой в то время (около 10 лет назад) было немного. При совершении перехода на другую страницу весь этот процесс повторялся. То есть раньше как такового разделения на фронтенд и бэкенд не было, было одно цельное приложение, которое одновременно и работало с базой данных, и генерировало HTML.

Где браузеру стоит хранить сессионные данные

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

Выделим 4 варианта хранилища, которые часто используют в современном мире:

• Cookie
• localStorage
• Session storage
• HttpOnly Cookie

Есть ещё IndexedDB — более сложный механизм хранения данных на стороне браузера, который нужен, в основном, для приложений с режимом офлайн. В этой статье рассматривать его не будем.

Cookie

Традиционный способ хранения информации на стороне клиента. Управлять этим хранилищем может как JS фронтенда, так и сервер через заголовок Set-Cookie. Cookies привязываются браузером к домену сервера и, в случае Same Origin Policy, будут автоматически подставляться в заголовки запросов к этому домену. При кроссдоменном запросе браузер будет требовать разрешение на обмен учётными данными — credentials. Cookies уязвимы к CSRF-атаке. В современных браузерах могут иметь опцию samesite, чтобы защититься от этой атаки, но с ней перестанут работать для кроссдоменных запросов. Кроме того, Cookie подвержены XSS атаке. Имеют ограничения по объему данных (4кб) и по количеству cookies на один домен.

localStorage

localStorage привязывается к документу источника (связка домен-протокол-порт), то есть, к фронтенд-странице. Любая вкладка этого источника в браузере имеет к нему доступ. Кроме того, браузер не отправляет автоматически на сервер данные, хранящиеся в localStorage, а значит, сервер самостоятельно не может ни писать, ни читать данные, что делает localStorage защищенным от CSRF. Ещё один значительный плюс — объём хранимых данных значительно больше, чем у Cookie. Несмотря на ряд преимуществ, localStorage никак не защищён от XSS-атак, что делает его опасным хранилищем для сессионных данных.

Session storage

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

HttpOnly Сookie

Выделяю этот способ отдельно от обычных Cookies, потому как у него есть одно решающее отличие: фронтенд-приложение не имеет доступа к Cookies с флагом httpOnly. Проще говоря, такие Cookies читать и писать может только сервер. Делает он это через заголовки cookie и set-cookie соответственно

Это важное отличие защищает их от XSS-атак. В сочетании со средствами защиты от CSRF, это хранилище весьма безопасно для сессионных данных

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

Что нужно уметь

Если вы откро­е­те вакан­сию любо­го бэкенд-разработчика, то там будут при­мер­но сле­ду­ю­щие требования:

• зна­ние Python, PHP, Ruby или Java (если всё сра­зу — это огром­ный плюс);
• часто хотят, что­бы вы зна­ли JavaScript и Node.js, что­бы реа­ли­зо­вы­вать часть логи­ки на клиенте;
• AJAX — помо­га­ет обнов­лять дан­ные на стра­ни­це без её перезагрузки;
• базы дан­ных — MySQL, PostgreSQL или MongoDB;
• Django и дру­гие фрейм­вор­ки для быст­рой разработки;
• уме­ние рабо­тать с API;
• вла­де­ние Git или любым инстру­мен­том кон­тро­ля версий.

Отдель­но ценит­ся уме­ние рабо­тать в UNIX-системах, раз­би­рать­ся в том, как устро­е­ны сете­вые тех­но­ло­гии и вла­де­ние сете­вы­ми про­то­ко­ла­ми. Но на самом стар­те мож­но и без этого.

Время простоя (downtime)

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

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

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

В любом случае, хороший фронтэнд должен всегда отлавливать ошибки в запросах с помощью try catch и иметь заготовленные ошибки для пользователя. В javascript нет встроенной функции(recovery panic), которая позволяет продолжить выполнение кода после ошибки, поэтому при её возникновении ваше приложение упадет.

Второй этап: системы контроля версий, фреймворки, паттерны проектирования — 4 месяца

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

Системы контроля версий

Время: 3–5 недель

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

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

Фреймворки

Время: 1–1,5 месяца

В современной веб-разработке мало что пишут с нуля, потому что есть инструменты и каркасы разработки, в которых уже заложена необходимая функциональность. Для начала советую фреймворки Yii2 или Laravel (Yii для новичка будет немного проще, но Laravel, на мой взгляд, лучше организован). Просто начните точно так же с изучения их документации и перепишите с нуля ваше приложение, которое вы написали в самом начале обучения. Реализация одной и той же идеи с помощью разных инструментов позволит увидеть принципиальные различия в коде. Если же старый проект вам наскучил, напишите что-то новое. Необязательно выдумывать стартап — просто возьмите готовую идею и перепишите по-своему, это для опыта, а не для выхода на IPO.

Очень рекомендую разбирать всё, с чем вы сталкиваетесь, как можно подробнее. Увидели QueryBuilder — напишите свой, если не делали этого, когда разбирались с PDO. Увидели роутинг — посмотрите, как он сделан во фреймворке, и попробуйте придумать его самостоятельно. Зачем? Во-первых, чтобы набить руку. Во-вторых, чтобы лучше понимать работу и внутренние процессы очень многих вещей и это не было для вас магией. В-третьих, как я говорил в самом начале, — чтобы создать резюме в виде репозитория своих проектов. Если хотите, можете даже попробовать написать свой домашний микрофреймворк, тоже интересный способ изучать эту область: у меня своих фреймворков как минимум два, их создание помогло мне разобраться с такой вещью, как метапрограммирование.

Паттерны проектирования

Время: 2–5 недель

В ООП есть раздел, о котором очень многие почему-то говорят с придыханием — это «шаблоны ООП» или паттерны. Само появление этого раздела и одноименной книги связано с тем, что разработчики раз за разом сталкивались с одними и теми же проблемами проектирования, в итоге был предложен список из 23 шаблонов, решающих типовые задачи. Это так, краткий экскурс в историю. Почему мы не занялись этим раньше? Потому что без практики сразу погружаться в эту достаточно академичную область сложно. Банальный пример — как объяснить устройство и пользу паттерна «Строитель» (Builder), если до этого человек не изучил QueryBuilder? Это будет слишком сложно.

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

Преимущества и недостатки профессии

К плюсам относится:

1. Профессия доступна и новичкам в программировании.
2. Должность имеет востребованность на рынке услуг.
3. Имеются перспективы карьерного роста.
4. Возможность взяться за крупные проекты и работать с зарубежными компаниями.
5. Высокая зарплата.

Минусы профессии:

1. Постоянное развитие и освоение новых технологий.
2. Отсутствие четкой границы и описания обязанностей. Руководитель может сам назначить функции и задачи работника. И это может стать для фронтенд-разработчика проблемой.
3. Зависимость от других специалистов и постоянное взаимодействие с ними. Не всегда получается все согласовать с первого раза, что приводит к замедлению процесса работы.

Третий этап: сопутствующие технологии — 4 месяца

Далее мы подходим к самой размытой части нашего плана — к многообразию сопутствующих технологий, и не только в области бэкенда, а программирования и разработки вообще. Разработка программного обеспечения безгранична, и ваши дальнейшие действия будут зависеть от ваших потребностей (или потребностей работодателя). Изучили Laravel или он вам просто надоел — изучайте Symfony, этот фреймворк не менее востребован. Захотели немного во фронтенд — изучайте JS, Angular, React, да хоть jQuery. Захотели изучить что-нибудь за пределами REST API — вебсокеты и GraphQL ждут вас. Хотите попробовать NoSQL, чтобы хранить документы, которые в обычную БД без боли не засунуть, или хранить настолько разрозненные данные, что никакой SQL не справится, — берите MongoDB или Redis и разбирайтесь до посинения. Хотите узнать, что такое поисковые движки и как у «взрослых дядь» работает текстовый поиск, — ElasticSearch и Sphinx к вашим услугам.

Обязательно изучите Docker — систему упаковки приложения для более удобного деплоя. Чем это может быть полезно для домашнего проекта? Если вы захотите сменить версию PHP или вообще язык, вам не придется что-то ставить на рабочую машину: достаточно поменять конфиги Docker, и приложение запустится без вашего участия. А еще немного поможет с пониманием, как взаимодействуют между собой отдельные части приложения: фронтенд, веб-сервер, бэкенд, база, что такое отдача статики (картинок и шрифтов). Таким образом, Docker позволяет не зависеть от окружения на сервере, от окружения на рабочем месте, упрощает сборку и развертывание проекта, повышает безопасность работы за счет изоляции всех частей приложения, в том числе и друг от друга. Маленький совет: если вы до сих пор работали на Windows, то настало время разобраться с Linux. Потому что Docker и Windows очень плохо дружат.

Если за год вы освоили все вышеописанное — я вам честно аплодирую. Потому что лично я в своё время освоил не всё из этого списка. Если не получилось, не отчаивайтесь и не спешите посыпать голову пеплом — все учатся по-разному.

Защита кода фронтенда от XSS

XSS-атака опасна только тогда, когда есть возможность вставить вредоносный код во фронтенд-содержимое, JS, HTML или даже CSS. Поэтому, во-первых, нужно стараться устранить такие возможности, а во-вторых, даже если злоумышленник смог поместить свои скрипты пользователю, сделать так, чтобы эти скрипты не достигли цели. С этим нам поможет CSP, описанный выше. Тем не менее, его недостаточно. Нужно обезопасить код одностраничного приложения от попадания чужого кода. О чём нужно помнить для этого при фронтенд-разработке:

1) Не доверяйте на 100% сторонним библиотекам. Собирать фронтенд современными сборщиками и проверять используемые пакеты с помощью npm audit (yarn audit). Если используете CI/CD, добавлять npm audit —audit-level=moderate перед шагом сборки. Если npm audit выявил уязвимости с уровнем moderate или выше, значит необходимо обновить эти библиотеки. Если обновление не помогло, стоит подумать, использовать ли эти пакеты. Эта мера защитит вас от большинства уязвимостей в подключаемых библиотеках.

2) Не вставляйте в код «чистые» значения переменных, которые потенциально могут содержать пользовательские данные. «Опасные» символы нужно экранировать. Рекомендуется делать это так:

Современные фронтенд-фреймворки сами прекрасно с этим справляются, если вы им не скажете обратного. Например, во Vue для вставки переменной в разметку следует использовать синтаксис mustache (`value`), а не атрибут v-html. Иногда возникают ситуации, когда всё же надо вставлять HTML из внешнего источника. Делать это позволительно только тогда, когда вы полностью этому источнику доверяете. Например, это сервисные сообщения, сгенерированные бэкендом. Но и в этом случае лучше подстраховаться и пропускать такие переменные через, например, HtmlSanitizer.

3) НИКОГДА не используйте в JS конструкцию . Поверьте, должен быть другой способ решения вашей задачи.

4) Не храните важные данные в Сookie. Если нужно хранилище сессий — договоритесь с бэкэнд-разработчиками и используйте только HttpOnly Сookie.

5) Не объединяйте на одном домене сайты разного назначения. Например, у вас есть сайт сервиса на какой-нибудь популярной CMS, доступный по домену service.test. Личный кабинет сервиса на этом же домене, но с другим path, например service.test/account, который использует localStorage. Если злоумышленник найдёт и воспользуется уязвимостью CMS для внедрения XSS, он сможет завладеть localStorage клиента личного кабинета.

6) Дополнительно ознакомьтесь с рекомендациями OWASP.

Подписка и тарифные планы

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

по проектированию тарифных планов:

• выделяйте рекомендуемый вариант;
• разрешите пользователям выбирать валюту (€/$/₽) и период оплаты (месяц/год);
• предоставьте первый месяц бесплатно для успешного вовлечения пользователей;
• особо выделите отзывы;
• продавайте преимущества вместо характеристик;
• дайте пользователям понять, что они могут отказаться в любой момент;
• разрешите пользователям выбирать интересующие характеристики и конфигурировать тарифные планы.

Как стать frontend-разработчиком с нуля

Должность верстальщика – первая ступень на пути к должности фронтенд-разработчика. Это самый распространенный вариант.

Но есть и другие пути – когда программист в начале своей карьеры знает, в какой области IT-сферы он хочет развиваться. Тогда начинающий специалист целенаправленно обучается ключевым навыкам, необходимым для выбранной профессии.

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

Чтобы стать frontend-разработчиком с нуля, первым делом познакомьтесь с HTML-кодом и возьмитесь за изучение CSS.

Затем перейдите к главному инструменту фронтенд-специалиста – JavaScript. Вникните в суть работы с фреймворками и системами контроля версий. Разберитесь в серверных технологиях. Основы веб-дизайна, текстовые и графические редакторы станут для вас плюсом во время поиска работы.

А дальше оттачивайте свои навыки, пополняйте знания.

Можно заниматься саморазвитием, читать тематическую литературу. Список книг по frontend-разработке есть на нашем блоге.

Более быстрый способ узнать все тонкости профессии – обзавестись наставником. Найти его можно на онлайн-курсах.

Где учиться

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

По завершении обучения вам выдадут сертификат и помогут составить резюме.

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

Вот несколько хороших курсов:

• Профессия Frontend-разработчик
• Frontend-разработчик с нуля
• React: библиотека фронтенд-разработки №1
• Специализация Frontend-разработчик
• Frontend-разработчик
• Профессия “Фронтенд-разработчик”

Узнать подробности и ознакомиться с полным перечнем курсов по frontend-разработке можно на нашем блоге.

Где работать

Frontend-developer требуются на предприятия, создающие софт для бизнеса, в IT-компании по разработке сайтов, мобильных и веб-приложений, web-студии, стартапы, агентства аутсорсинга.

Карьерная лестница начинается с пункта “стажер”. Работа позволит набраться опыта и узнать на практике, что такое фронтенд-разработка.

Вакансии можно найти на профильных IT-ресурсах или на популярном сервисе по поиску работы hh.ru.

Если вам достаточно подработки или вы еще совсем “зеленый”, найти работу и испытать себя можно на биржах фриланса. Есть международные сервисы, например, Upwork, Freelancer, Joomlancers, Gigster, Codeable и YouTeam. А есть русскоязычные: Kwork, FL, Freelance.

Биржи помогут начинающим программистам набить руку, собрать портфолио и научиться работать с заказчиками.

У опытного специалиста есть три варианта совершенствования в работе:

1. Вертикальный – рост по карьерной лестнице, постепенное завоевание новых должностей.
2. Горизонтальный – непрерывное совершенствование своих навыков, что приводит к повышению цены за свои услуги.
3. Диверсификационный – обретение новых навыков, смежных специальности фронтенд-разработчик, и последующая переквалификация. Так часто frontend-developer превращается в backend-разработчика.

Где найти backend программиста на проект?

• В интернете есть много профильных ИТ-сайтов, на которых можно бесплатно разместить объявление о поиске разработчика.
• Посмотрите каталог веб-программистов. При помощи фильтров в каталоге можно найти разработчиков, владеющих нужными вам технологиями.

• Добавьте проект на биржу для программистов. Добавление вакансий на ней – бесплатное.

Рекомендуем

Профессия модератор группы

Модератор группы – профессия, которую можно быстро освоить самостоятельно. Она подойдет тем, кто хочет подработать в интернете, но не обладает …

Профессия звукорежиссер

Звуки способны вызывать определенные эмоции, чувства, реакции. Звукорежиссер – это специалист, который создает звуковые образы в кино, театре, …

Что в итоге

Backend-разработка стала для меня еще одним хорошим опытом – я научился писать код и проводить ревью, продумывать архитектуру. Это на самом деле интересно.

Но при этом, попробовав вживую что фронт, что бэк, я не скажу, что в случае чего сразу выбрал бы бэкенд в самом начале карьеры

Для меня все же важно видеть и понимать, как мой продукт воспринимают пользователи. С бэкендом это все довольно призрачно

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