Фронтенд и бэкенд: на что падет выбор?

Что обязан уметь и знать Frontend-разработчик: ключевые навыки, требования и инструменты


Frontend-разработчику приходится становиться хорошим верстальщиком

  • кроссбраузерная адаптивная верстка полученных от web-дизайнера макетов в PSD-формате – удобное отображение веб-сайта в существующих браузерах на экранах любых устройств;
  • кроссбраузерная адаптивная верстка e-mail писем для рассылок – каждый почтовый клиент читает код по-своему, а нужно, чтобы письмо отображалось везде одинаково;
  • валидная верстка – соответствие стандартам W3C;
  • семантическая верстка – осмысленное расположение фрагментов кода на странице, правильное использование тегов, понятные названия классов и идентификаторов;
  • оптимизированная под поисковые системы верстка – скорость загрузки, структурированный код, акценты для поисковых систем, теги title, description и alt + title для изображений;
  • верстка под CMS (готовые движки сайтов) – разработка целостных шаблонов и их «натяжка» на CMS.

Инструменты верстальщиков:

    • SMACSS, а также BEM и еще OOCSS – это принятые во всем мире стандарты разработки структурной части CSS;
    • AJAX/jQuery – требуются для разработки любых динамических элементов на веб-страницах, а еще для создания форм онлайн-заявок;
    • CSS-препроцессоры – дают возможность разрабатывать CSS намного скорее;
    • Photoshop – нужен для разделения PSD-макетов на составные элементы;
    • SVG/Canvas – для обработки применяемых изображений;
    • HTML/CSS – требуется максимальный уровень знаний, т. к. это ключевые для верстальщиков инструменты. Больше всего времени стоит уделить знакомству с Grid CSS, а также Flex box;
    • MediaQueries – используется, чтобы выполнять и проверять кроссплатформенную и кроссбраузерную виды верстки;
    • Шаблонизаторы – чтобы подставлять данные в динамическом режиме;
    • WordPress и Drupal, OpenCart и Joomla, MODx и Bitrix и пр. – распространенные движки сайтов (CMS).

    Чтобы приступить к выполнению обязанностей верстальщика, понадобятся для начала знания кроссбраузерной адаптивной верстки. Все прочее придет со временем. Профессиональный уровень верстальщиков зависит от того, насколько он разбирается в языке Java Script и сложных функциях движков (CMS). Касательно JavaScript следует отметить, что верстальщикам обычно достаточно изучить две библиотеки – AJAX и jQuery.

Изучив верстку, нужно погрузиться в JavaScript, разобравшись:

  • в принципах языка – ECMA Script 5, 6 и последний7;
  • в сборщиках Java Script: Gulp, Web Pack и Grunt;
  • в популярных фреймворках и библиотеках, среди которых: React и Knockout, Vue и Backbone, Ember и Svelte, GWT и Angular, ExtJS и Polymer, RxJS и Dojo, Redux и пр.;
  • с тем, как функционирует браузер в части рендеринга JavaScript и построения DOM;
  • с прогрессивными интернет-приложениями: Storage и Web Sockets, Service Workers с изучением разнообразных API, задействованных для PWA;
  • с тестированием приложений: Karma и Jest, Enzyme и Chai, Cypress и Ava, Mocha и др.

После изучения JavaScript открываются широкие перспективы (читай больше об этом в «»).

Технологии, Которые Вам Нужно Будет Знать

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

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

Набор Инструментов Front End

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

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

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

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

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

Did you know?

Have you ever wondered which online learning platforms are the best for your career?

See & compare TOP3 online learning platforms side by side

Набор Инструментов Back End

Итак, давайте приступим к следующей части изучения Фронтенд и Бэкенд инструментов. Инструменты фронтенд разработчика обычно довольно популярны. Однако в случае с бэкенд разработчиком всё совсем не так.

Языки программирования серверной части

Выбор языков программирования зависит от предпочтений, нужд проекта и ваших знаний. Существует несколько популярных языков программирования серверной части, вроде PHP, JavaScript (используемых в среде Node.js с фреймворком Express), Python, Ruby, C#, Java и другие.

Используемые технологии также могут определить язык, которые вы собираетесь использовать. Например, если ваш сайт создан на Symfony или Laravel, то вам придётся использовать PHP. Для фреймворка Django более предпочтительным станет Python, тогда как работа с фреймворком Express потребует от вас знаний Node.js.

База данных

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

Существует несколько популярных систем баз данных, вроде MongoDB, MySQL, Oracle, Redis и другие.

Итак, front end и back end инструменты мы рассмотрели, давайте перейдём к следующей теме.

Немного практики с сессионными токенами и защита от CSRF

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

Для начала сделаем такой токен доступа, у которого будет небольшой срок жизни. Тогда злоумышленник, предпринимающий атаку на похищение токена, может не успеть им воспользоваться даже в случае кражи. Однако если сделать период действия слишком коротким, обычному пользователю будет неудобно: перелогиниваться каждые 10 минут — то ещё удовольствие. Поэтому токены можно разделить на 2 вида: токен доступа (access_token) и токен обновления (refresh_token). С помощью access_token пользователь получает доступ к ресурсам API, а с помощью refresh_token пользователь запрашивает у API новый access_token. В чем же смысл? Злоумышленник ведь может украсть refresh_token и с помощью него получить действительный access_token. Для того, чтобы разобраться в этом, давайте рассмотрим небольшую модель с REST API.

Пусть эндпоинт аутентификации POST /auth имеет следующий вид:

ЗапросОтвет
Body

Пользователь вводит свой логин и пароль, в теле ответа получает access_token. Фронтенд-приложение этот токен запоминает и далее может делать авторизованные xhr-запросы, например GET /user

ЗапросОтвет
Body
Headers

Время жизни access_token, предположим, 10 минут, значит, через 10 минут пользователю придется перелогиниться для продолжения работы в приложении. Чтобы пользователя «не выбрасывало», нужен refresh_token, время жизни которого существенно выше, например, сутки. Тут встаёт вопрос, где же хранить эти токены со стороны браузерного клиента, ведь очевидно, что хранить их вместе не стоит. Рассматривать будем только 2 вида хранилища: localStorage, способное держать информацию в рамках одного источника одностраничного приложения, и httpOnly Cookie, привязанное к конкретному домену бэкенда

Session storage привязан к конкретной вкладке, поэтому не подходит, а обычные Cookie слишком небезопасны.
Важно понимать, что refresh token нужен только пользователям веб-страницы, а пользователи, обращающиеся к API со своих серверов, могут сами обновлять access_token при помощи логина и пароля

Приложение на другом сервере, обращающееся к нашему API, не использует Cookie для общения. Ему необходимо добавлять access_token в заголовок запроса для подтверждения авторизации. Фронтенду тоже нужен доступ к access_token для добавления этого заголовка. Поэтому использование localStorage в качестве хранилища access_token — неплохой путь с учётом небольшого времени жизни и принятых мер по защите от XSS. А в качестве хранилища для refresh_token стоит использовать httpOnly cookie. Тогда в бэкенде нужно сделать так, чтобы на запрос авторизации POST /token/auth он формировал ответ с соответствующим заголовком Set-cookie.

ЗапросОтвет
Body
Headers

Мы помним, что любые cookies уязвимы к CSRF-атакам. Необходимо защитить refresh_token от CSRF атак дополнительно CSRF-токеном. Что? Ещё один токен? А его где хранить? Дополнительный токен не нужен, с задачей хорошо справится access_token. Используем его для проверки, что запрос POST /refresh выполнен санкционировано от авторизованного пользователя.

В эндпоинте POST /token/refresh используем для проверки сразу 2 токена: старый access_token взятый из localStorage и refresh_token взятый из httpOnly cookie при помощи заголовка cookie

ЗапросОтвет
Body
Headers

Со стороны бэкенда проверка access_token из заголовка X-CSRF-Token должна пропускать случай, если этот токен уже просрочен, но не так давно (~ время жизни refresh_token).
Важно знать, что если мы работаем в рамках политики CORS, то при совершении XHR-запроса с участием cookie нужно проводить такой запрос со специальным флагом withCredentials: true для XMLHttpRequest и credentials: ‘include’ для fetch. Без этого флага браузер запретит использовать cookie, в том числе и httpOnly, серверу с доменом, отличным от домена источника

Таким образом, храня access_token и refresh_token в разных хранилищах, используя доступные средства защиты от XSS и CSRF-атак, мы сделаем наше приложение безопаснее.

API

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

Цели для нового API сформировались из ежедневных трудностей в реализации новых продуктовых и дизайнерских идей. Нам были нужны:

  1. Слабая связанность компонентов системы, чтобы бэкенд и фронтенд можно было развивать параллельно.
  2. Высокая масштабируемость, чтобы новый API не мешал наращивать функциональность.
  3. Стабильность и согласованность.

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

Наиболее распространены разного рода REST API. В последние годы к ним добавляют описательные модели через инструменты типа swagger, но нужно понимать, что это тот же REST. И, по сути, его главный плюс и в то же время минус — это правила, которые носят исключительно описательный характер. То есть никто не запрещает создателю такого API отклоняться от постулатов REST при реализации отдельных частей.

Другим распространённым решением является GraphQL. Он тоже не идеален, но в отличие от REST, GraphQL API — это не просто описательная модель, а настоящие правила.

Выше я говорил про систему, которая должна была согласовывать работу фронтенда и бэкенда. Прослойка (interlayer) — это именно тот промежуточный уровень. Рассмотрев возможные варианты работы с сервером, мы остановились на GraphQL в качестве API для фронтенда. Но, так как бэкенд написан на C++, то реализация GraphQL-сервера оказалась нетривиальной задачей. Не буду здесь описывать все возникшие сложности и ухищрения, на которые мы шли, чтобы их преодолеть, реального результата это не принесло. Посмотрели на проблему с другой стороны и решили, что простота — залог успеха. Поэтому остановились на проверенных решениях: отдельный Node.js сервер с Express.js и Apollo Server.

Далее нужно было решить, как обращаться к API бэкенда. Сначала смотрели в сторону поднятия REST API, потом пробовали использовать аддоны на C++ для Node.js. В итоге поняли, что это всё нам не подходит, и после подробного анализа для бэкенда выбрали API на базе gRPC-сервисов.

Собрав воедино полученный опыт использования C++, TypeScript, GraphQL и gRPC, мы получили архитектуру приложения, позволяющую гибко развивать бэкенд и фронтенд, продолжая при этом создавать единый программный продукт.

Получилась схема, где фронтенд общается с промежуточным сервером с помощью GraphQL-запросов (знает, что спросить и что получит в ответ). GraphQL-сервер в резолверах вызывает API функции gRPC-сервера, при этом для связи они используют Protobuf-схемы. API-сервер на базе gRPC знает, у какого микросервиса взять данные, или кому передать полученный запрос. Сами микросервисы при этом тоже построены на gRPC, что обеспечивает скорость обработки запросов, типизацию данных и возможность использования различных языков программирования для их разработки.

Общая схема работы после изменения архитектуры

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

PHP

Это язык, на котором написана большая часть Интернет. Можно быстро запускать веб-приложения с использованием готовых платформ типа WordPress, Laravel, Symfony.

Можно писать бекенд с REST API, где хорошо себя показывает Symfony или Headless WordPress. Laravel тоже вполне себе подходит, если есть нужные разработчики.

PHP — отличный язык для начинающих по ряду причин:

  • он прощает ошибки: вы можете запустить программу, и она будет выполняться, пока не достигнет участка с проблемным кодом;
  • у языка большое сообщество, а для новичков доступно много обучающих материалов. Язык постоянно обновляется, поэтому убедитесь, что изучаете последнюю версию;
  • установить и настроить PHP достаточно легко по сравнению, например, с Ruby on Rails. Вы можете скачать MAMP (для Mac) или WAMP (для Windows), и всё будет готово к работе через 5 минут.

Ничего не мешает вырости до больших сайтов и нагрузок, как в случае с Facebook, Avito, Badoo, WordPress.com.

Что можно делать на PHP

Согласно официальному сайту PHP, вы можете:

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

Минусы PHP

Этот язык часто критикуют за отсутствие асинхронности и event loop. Хотя стоит отметить что это не его территория. На нем обычно пишут бизнес логику и там это скорее плюс чем минус.

Однако построить на нем высоконагруженный REST API микросервис достаточно сложно. Можно конечно использовать дополнительные компоненты типа PHP Swoole или PHP RoadRunner, но иногда все таки лучше смотреть в сторону NodeJS, Golang или Rust.

Тут выбор также очень сильно зависит от тех команд что есть в компании и от их компетенций.

Инфраструктура: docker-compose

  • Создаётся контейнер MongoDB и контейнер Redis.
  • Создаётся контейнер нашего бэкенда (который мы опишем чуть ниже). В него передаётся переменная окружения APP_ENV=dev (мы будем смотреть на неё, чтобы понять, какие настройки Flask загружать), и открывается наружу его порт 40001 (через него в API будет ходить наш браузерный клиент).
  • Создаётся контейнер нашего фронтенда. В него тоже прокидываются разнообразные переменные окружения, которые нам потом пригодятся, и открывается порт 40002. Это основной порт нашего веб-приложения: в браузере мы будем заходить на http://localhost:40002.
  • Создаётся контейнер нашего воркера. Ему внешние порты не нужны, а нужен только доступ в MongoDB и Redis.

серияпереводовпрекрасныхстатей

целая отдельная статьяразвернутой дискуссии на StackOverflow

  • всё кешируется как ожидается (на нижнем слое — зависимости, на верхнем — билд нашего приложения);
  • отрабатывает как надо и модифицирует в нашем репозитории (что было бы не так, если бы мы использовали COPY, как многие предлагают). Запускать просто вне контейнера в любом случае было бы нежелательно, потому что некоторые зависимости нового пакета могут уже присутствовать и при этом быть собраны под другую платформу (под ту, которая внутри докера, а не под наш рабочий макбук, например), а ещё мы вообще не хотим требовать присутствия Node на разработческой машине. Один Docker, чтобы править ими всеми!

Перед началом: стек и задачи

Для успешного освоения годового плана обучения программированию я рекомендую придерживаться следующих правил:

  1. Старайтесь выделить хотя бы два часа в день. Не каждый, но желательно.
  2. Не ограничивайтесь одним источником информации. Параллельно с официальной документацией читайте форумы, изучайте курсы, задавайте глупые вопросы гуглу и смотрите видеоуроки. Но не злоупотребляйте последним — чревато ролью пассивного зрителя.
  3. Избегайте скуки. Нужно постоянно придумывать себе «‎челлендж». Как писал автор одной книжки для начинающих: «Это же программирование! Развлекайтесь!»
  4. Помните, что этот план — не истина в последней инстанции. Меняйте его под себя с учетом своих особенностей.

План универсален: всё, что будет различаться в другом стеке, это название языка и список сопутствующих технологий. Замените PHP на Python (Django), Ruby (Ruby on Rails) или C# (ASP.NET), а MySQL — на PostgreSQL или MSSQL, ничего не поменяется. А в двух самых популярных редакторах кода — IntelliJ IDEA и VS Code — поддержка того или иного языка включается пятиминутной установкой плагинов.

В нашем случае язык программирования — PHP. Рядом с ним будут стоять веб-сервер nginx (не люблю Apache) и любая база данных (допустим, MySQL). Это мейнстримное решение в стеке PHP, поэтому остановимся на нем.

Что мы встретим в краях бэкенда

  • объектно-ориентированное программирование (ООП);
  • работа с базой данных — например, повесить индекс или оптимизировать запрос;
  • работа с API на отправку и на получение данных;
  • приложения с MVC-архитектурой;
  • работа с хранилищами данных и сторонними сервисами;
  • паттерны проектирования;
  • система контроля версий.

Не расслабляйтесь, на этом список не заканчивается. Это базовые требования к человеку, который претендует на работу бэкенд-разработчика.

Работа с Open Source

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

  • читайте документацию и ищите ответы в ней, прежде чем задавать вопросы;
  • посетите официальную страницу пакета на GitHub или Bitbucket, просмотрите открытые и решенные проблемы, и, возможно, вы найдете пулл реквест, в котором будет необходимая функциональность;
  • также вы можете сами реализовать необходимую функциональность и отправить ее авторам, внеся свой вклад в развитие Open Source. Если ваш код не приняли, просто используйте свою версию вместо исходного пакета;
  • если вы все-таки вынуждены писать свои функции с нуля, то убедитесь, что вы создаете их для универсального применения, чтобы другие тоже могли их использовать.

Различные Сферы Влияния: Фронтенд и Бэкенд

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

Итак, frontend backend разработчики и их обязанности, давайте начинать!

Для начала давайте сравним то, чем Фронтенд и Бэкенд разработчики занимаются. Это не очень сложная тема, так как отличия весьма разительные, несмотря на одну сферу деятельности.

Как Работают Сайты?

Чтобы объяснить работу сайта, давайте используем в качестве примера один из самых популярных. Amazon.com должен стать отличным примером для этого.

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

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

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

Какую часть делал Фронтенд и Бэкенд разработчик в этом случае?

Всё, что вы видите на сайте Amazon было создано фронтенд разработчиками. Кнопки, список товаров, страница товаров, страница оплаты, практически всё.

Но.

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

Если вы хотите создать сайт, то это не front end vs back end. Это front end и back end вместе.

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

Кто такой backend-разработчик и чем он занимается?

Современные веб-приложения, сайты и интернет-сервисы состоят из frontend и backend частей. Давайте посмотрим, чем они отличаются:

  • Frontend отвечает за ту часть кода, который выполняется в вашем браузере. Например, то, что сайт хорошо выглядит на разных устройствах, все кнопки и формы работают, как нужно – это заслуга frontend-разработчика.
  • Backend-часть сайта – это код, который выполняется на сервере, откуда вы загружаете сайт или интернет-сервис. Например, вы задаете запрос в поисковую систему. Ваш запрос попадает на сервер, который осуществляет поиск информации в базе данных и формирует ответ на ваш запрос. Процесс поиска и формирования ответа из базы – это backend-часть поисковой системы.

Кратко задачи бэкенд программиста можно описать следующим образом:

Проектирование архитектуры веб-приложений.

Создание или доработка ядра сайта.

Создание оптимальных алгоритмов для осуществления вычислений

Важно, чтобы вычисления проводились быстро и требовали минимум ресурсов.

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

Повышение безопасности интернет-сервисов.

Разработка API для интеграции веб-сервиса с другими сайтами.

Создание и управление базами данных.

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

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

Content Security Policy

Ещё один заголовок, о котором стоит рассказать отдельно, — Content Security Policy. Это очень мощный инструмент, который соединил в себе другие заголовки безопасности, такие как x-xss-protection или x-frame-options. С его помощью можно «попросить» браузер ограничить список ресурсов, допущенных к общению с вашим фронтенд-приложением. Каждый вид ресурсов настраивается отдельно: картинки, JS-скрипты, CSS, шрифты, XHR-запросы и др. Вы можете сказать браузеру, что XHR-запросы можно слать только на конкретные домены, картинки брать только с определённых ресурсов и т.д.

CSP можно прописать в заголовках ответа веб-сервера:

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

Либо в тэге мета-заголовке HTML-страницы:

Кроме того, CSP может запретить изменение и добавление inline-стилей и скриптов. Даже если XSS пролезла на сайт, браузер не позволит ей обмениваться данными со злоумышленником и выполнять зловредные операции.

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

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

Выделим 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, это хранилище весьма безопасно для сессионных данных

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

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий