Как сделать авторизацию на сайте: вход, сессия и права доступа

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

Что именно нужно защищать

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

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

• Публичные страницы: доступны без сессии и не содержат персональные данные.
• Личный кабинет: сессия обязательна, а сервер сверяет владельца каждой записи.
• Панель сотрудников: одной сессии мало, нужны отдельные права на действия.
• Административные операции: выдаются минимальному числу людей, после смены роли доступ пересматривается.

Как выбрать основу для входа и сессии

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

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

По теме: Как сделать интерактивный сайт: фильтр карточек с проверкой

Как собрать рабочий путь пользователя

Для большинства сайтов достаточно входа по почте или через доверенного провайдера, серверной сессии и проверки прав на защищённых действиях. Секрет сессии помещайте в cookie с Secure, HttpOnly и уместным SameSite; первый флаг ограничивает передачу HTTPS, второй не даёт читать cookie скрипту, третий помогает ограничить межсайтовые отправки (MDN). SameSite само по себе не заменяет защиту от поддельных запросов (OWASP).

1. Опишите страницы входа, кабинета, выхода и восстановления доступа. Если регистрации нет, уточните, кто создаёт учётные записи.
2. Подключите готовый механизм проверки личности и создавайте новую серверную сессию после успешного входа. Пустая форма входа без серверной проверки не защищает данные.
3. На сервере поставьте общую проверку сессии перед закрытыми маршрутами и API. При отсутствии действующей сессии закрытые данные не должны выдаваться.
4. После проверки сессии сравните право на действие и владельца объекта. Пользователь с действительным входом не должен читать чужой заказ, просто заменив его номер в адресе.
5. Сделайте выход: отзовите сессию на сервере, удалите cookie в браузере и проверьте, что старую ссылку нельзя открыть снова.
6. Добавьте восстановление доступа по одноразовой ссылке с ограниченным сроком, одинаковым ответом для существующего и чужого адреса и отзывом старых сессий после смены пароля.

OWASP советует закрывать доступ по умолчанию и проверять разрешение на каждом запросе, включая вызовы API (руководство по авторизации). При восстановлении ссылка должна быть одноразовой, а ответ сайта не должен выдавать, существует ли почта в базе (руководство по восстановлению).

Никогда не храните идентификатор сессии или ключ входа в localStorage. Скрипты страницы могут прочитать такое хранилище; OWASP рекомендует защищённую cookie и серверную проверку.

Для этой границы полезно заглянуть в руководство OWASP по сессиям. Сам пароль, если вы храните его сами, должен проходить через специальный алгоритм хранения паролей, а не попадать в базу открытым текстом (OWASP).

Как проверить доступ до запуска

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

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

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

По теме: Как сделать политику конфиденциальности на сайт: план и проверка

Когда такой путь не подходит

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

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

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

Можно ли сделать авторизацию без регистрации?

Да. Учётные записи может создавать администратор или внешний провайдер. Вход и проверка прав всё равно нужны.

Достаточно ли скрыть страницу кабинета?

Нет. Сервер должен защищать и саму страницу с данными, и API, из которого она получает записи.

Зачем проверять права, если человек уже вошёл?

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

Что должно происходить после выхода?

Сервер отзывает сессию. Повторный запрос к закрытым данным со старой cookie больше не проходит.