Соображения безопасности букмарклета, CSRF, хэшированный ключ

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

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

Я думал, что придумал, как это сделать, но потом понял, что у этого способа масса проблем.

Оригинальная идея

• генерировать случайный ключ, который включается в букмарклет-ссылку. Хэш ключа сохраняется в базе данных. Случайный ключ дает доступ ТОЛЬКО к привилегии вставки в эту коллекцию и не может быть использован где-либо еще.
• букмарклет загружает более длинный скрипт с моего сервера, поэтому я мог бы поставить токен для предотвращения CSRF таким образом
• требуется, чтобы пользователь вошел в систему

Проблемы

• Если у меня есть ключ букмарклета, нужны ли мне встречные токены CSRF?
• Есть ли способ защитить ключ букмарклета, если пользователь щелкнет букмарклет на вредоносном сайте?
• Я не хочу, чтобы имя пользователя и пароль хранились в ссылке букмарклета, потому что тогда любой, кто имеет доступ к компьютеру, получит и пароль, поэтому я остановился на случайном ключе.
  • но если я буду хранить только хэш, я не смогу сгенерировать одну и ту же ссылку букмарклета дважды, поэтому, когда пользователь захочет использовать букмарклет в другом браузере/компьютере, ему придется утомительно импортировать ссылку из старого браузера или прервать поддержку старого.
  • но я не должен хранить ключ с открытым текстом, потому что кто-то, получивший доступ к базе данных, может использовать этот ключ для вставки строк в учетные записи, которые ему не принадлежат.
  • Возможное решение Я могу попросить пользователя указать свой пароль каждый раз, когда он создает букмарклет, хэшировать пароль много раз, поместить этот хэш в URL и поместить хэш этого хэша в мою базу данных. Но, конечно, это открывает гораздо худшие дыры в безопасности.
    • Я мог бы сделать это с чем-то вроде "девичья фамилия матери" вместо этого
    • Я не могу использовать bcrypt для хэширования из-за случайной соли, верно? Какая хэш-функция будет правильной? Или вы отвергнете всю идею?
• Если я оставлю ключ букмарклета в стороне, вредоносный сайт может просто встроить букмарклет и извлечь из него действительный токен CSRF, верно?

Есть идеи получше? Или вы не можете иметь CSR без F?

Редактирование, уточнение случая использования

Одна вещь, о которой я просто не подумал, это использование iframe, как предложил Sripathi Krishnan.

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

Однако, на самом деле, мой букмарклет в настоящее время делает некоторые базовые взаимодействия с сайтом во время выполнения (то есть форма уже есть, и пользователь может изменить свой выбор в DOM сайта, что должно изменить форму). Я готов отказаться от этой функциональности для моего случая использования, если окажется, что нет достаточно безопасного способа отличить поддельные межсайтовые запросы от неподдельных - но мне все еще интересно на теоретическом уровне.