История изменений

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

Для POST/PUT/PATCH/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/PATCH/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

Кстати, если очень лень, можно добавлять тот же токен, что и лежит в куке, а на бекэнде просто сравнивать токен из куки и токен переданный в дополнительном заголовке или скрытом поле формы (разумеется, токен из куки валидируется стандартым образом). Так как сторонний сайт не сможет прочитать куку, чтобы достать оттуда токен и добавить его в заголовок или форму. Но в этом случае отпадает возможность использовать HTTP-only кук (защита от угона сессии с помощью XSS), так что подход имеет не только плюсы, но минусы.

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage. Соответственно, строннему сайту этот токен будет недоступен и он добавить этот заголовок не сможет с валидным токеном.

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.

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

Для POST/PUT/DELETE запросов, которые уже потенциально опасны даже без доступа к ответу сервера, можно требовать передавать токен не в куке, а, например, в заголовке Authorization, куда его будет подсовывать клиентский JS, который будет этот токен получать с помощью GET запросов или читать из localStorage.

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

сессия теряется при закрытии вкладки

С чего бы ей теряться. Если хочется длительных сессий, то токен можно сохранить в localStorage (вечная сессия, если только юзер не удалит принудительно данные сайта) или sessionStorage (сессия до закрытия последней вкладки браузера, но доступная во всех открытых вкладках сайта включая новые). Если хочется, чтобы сессия имела срок действия как куки, то можно использовать JWT или аналог, которые бекэнд будет генерировать с нужным сроком действия и проверять при каждом запросе.