Отключить History API

[Белый шум]

brizing,
тогда у вас как-то неправильно токен реализован, ибо такой запрос должен выдавать страницу авторизации. Правильный запрос должен выглядеть как-то так:
$.get('/account?token=jtd9876vglijhkyrf53phj0');
- конкретное значение токена хранится в сессии, а ссылки с токеном присутствовать только на страницах админки (после авторизации).

[Aetae]

Белый шум,
Если "админ после авторизации" зайдёт на страницу на том же домене с "юзерским" скриптом - то всё, гейм овер, скрипту доступно всё.
brizing,
Для недоверенных скриптов - только другой домен. Помимо очевидных вариантов, что вам указали, есть ещё сотни неочевидных.

[Белый шум]

Aetae,
токены не должны содержаться в ссылках на неадминскую часть сайта (или где-либо ещё в неадминской части).
Ребята, ну вы чего - токенов никогда в действии не видели?

[Aetae]

Белый шум, это ты путаешь.
Юзер заливает скрипт в /user, админ логинется в /admin и идёт в /user, скрипт с /user спокойно запрашивает /admin и забирает токены. Конец.
Токены защищают от csrf, важное тут cs - cross site. В пределах сайта это никакой защиты не даёт.

[Белый шум]

Aetae,
ещё раз: если скрипт с /user запрашивает /admin, то в ответ получает страницу авторизации. Смысл токенов в том и состоит, что получить его можно только при авторизации, после чего его нужно передавать при каждом запросе к админской части сайта:
- запросил /admin?token=jtcvbliugkbk - получил содержимое страницы
- запросил /admin - получил сообщение "неверный токен" и форму авторизации

[Aetae]

Белый шум, откуда админ возьмёт этот ваш jtcvbliugkbk?
Из куки? /user имеет доступ к куки.
Из ссылки в теле страницы? /user имеет доступ к телу страницы.
Человек переходя на /admin каждый раз заново авторизуется, а переходя по любой другой внутрисайтовой ссылке авторизацию теряет? Никто так делать не будет, т.к. неудобно. При том всё равно, если у такого "админа" случайно окажется висеть открытая вкладка с /user при заходе на /admin, то, как только авторизация пройдёт, скрипт с /user повторяющийся с интервалом получит все доступы.

[Белый шум]

откуда админ возьмёт этот ваш jtcvbliugkbk?

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

/user имеет доступ к телу страницы.

/user - не админская страница, соответственно у неё нет доступа к токену.

Человек переходя на /admin каждый раз заново авторизуется, а переходя по любой другой внутрисайтовой ссылке авторизацию теряет? Никто так делать не будет, т.к. неудобно.

Именно так и делают. Админская часть в одних вкладках, юзерская - в других. Немного неудобно, согласен, зато безопасно.

При том всё равно, если у такого "админа" случайно окажется висеть открытая вкладка с /user при заходе на /admin, то, как только авторизация пройдёт, скрипт с /user повторяющийся с интервалом получит все доступы.

Не получит, ибо нет доступа к токену.

[brizing]

Соглашусь, /admin?token=jtcvbliugkbk - это неудобно и, допустим, это крайний вариант.

Замечу также, что ссылка /admin?token=jtcvbliugkbk не должна давать доступ с другого устройства. Т.е. нужно ещё устанавливать авторизационную куку. Если кукак И токен валидные, выдавать админку.

Однако, document.referrer на странице /user может содержать "/admin?token=jtcvbliugkbk".
Чтобы этого избежать, на странице /admin необходимо размещать ссылку:

<a href="/redir?/user" target="_blank">

[Aetae]

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

[brizing]

Даже при наличии в админке ссылки /redir?/user,
админ может, находясь на странице /admin?token=jtcvbliugkbk, вставить в адресную строку ссылку /user, перейти туда и будет доступен document.referrer (ой, ниже подсказали, что не будет).

Сервер должен блокировать /user, если HTTP_REFERER == /admin