Политика одного источника и изоляция данных

Механизм хранения данных в браузере жёстко подчиняется модели same-origin policy (политики одного источника), которая является базовым элементом безопасности веб-платформы. Эта модель определяет, что данные, сохранённые одной веб-страницей, могут быть доступны только другим страницам, имеющим идентичный источник, состоящий из схемы (protocol), домена (host) и порта. Любое отклонение хотя бы в одном из этих параметров формирует новый изолированный контекст хранения.

Библиотека localForage полностью наследует эту модель и не предоставляет способов её обхода, поскольку она опирается на нативные браузерные API — IndexedDB, WebSQL и localStorage. В результате вся архитектура изоляции данных определяется не самой библиотекой, а средой выполнения.


Источник как граница хранения

Понятие origin формирует фундаментальную границу, внутри которой происходит вся работа localForage. Например:

  • https://example.com
  • https://sub.example.com
  • http://example.com
  • https://example.com:8080

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

Даже смена протокола с HTTPS на HTTP формирует отдельное хранилище, поскольку безопасность рассматривает такие контексты как несовместимые.


Изоляция через IndexedDB

При использовании IndexedDB localForage получает наиболее строгую и формализованную модель изоляции. Каждому источнику соответствует отдельная база данных, внутри которой создаются object stores. Браузер гарантирует:

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

Эта изоляция реализована на уровне движка браузера и не зависит от JavaScript-кода.

localForage лишь абстрагирует операции:

  • setItem(key, value)
  • getItem(key)
  • removeItem(key)
  • clear()

но не влияет на область видимости данных.


Поведение localStorage и sessionStorage

При переключении драйвера localForage может использовать localStorage или sessionStorage, однако принцип изоляции остаётся неизменным.

localStorage

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

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

sessionStorage

Дополнительный уровень изоляции накладывается поверх origin — данные разделяются не только по источнику, но и по вкладке браузера. Это создаёт более узкую область видимости:

  • одна вкладка = один контейнер sessionStorage
  • закрытие вкладки уничтожает данные

localForage при использовании sessionStorage наследует эти ограничения полностью.


WebSQL как устаревшая модель изоляции

WebSQL, несмотря на статус устаревшего стандарта, также сохраняет модель изоляции по origin. Каждая база данных принадлежит конкретному источнику и не может быть прочитана извне.

localForage может использовать WebSQL в старых браузерах, но поведение изоляции остаётся эквивалентным IndexedDB:

  • базы данных не пересекаются между origin;
  • нет механизма междоменного доступа;
  • данные доступны только в контексте текущего origin.

Пространство ключей и отсутствие глобального доступа

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

  • каждый origin имеет собственное изолированное хранилище;
  • внутри одного origin localForage использует единый namespace;
  • перекрытие возможно только внутри одного приложения, если разработчик сам допускает конфликт ключей.

Таким образом, изоляция работает на двух уровнях:

  1. межсайтовый уровень (origin isolation);
  2. внутрисайтовый уровень (key namespace).

Поддомены и границы изоляции

Поддомены рассматриваются браузером как отдельные источники. Следовательно:

  • app.example.com
  • admin.example.com

не имеют доступа к данным друг друга через localForage.

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


Порт как часть источника

Порт является полноценной частью origin. Следовательно:

  • http://localhost:3000
  • http://localhost:5173

имеют полностью независимые хранилища.

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


Изоляция в контексте приватного режима

Инкогнито-режим браузеров усиливает изоляцию, но не нарушает её модель. В этом режиме:

  • хранилища могут быть временными;
  • IndexedDB и localStorage могут быть очищены при закрытии сессии;
  • каждый origin остаётся изолированным, как и в обычном режиме.

localForage не различает приватный и обычный режим на уровне API — различия определяются только поведением браузера.


Смешанные источники и безопасность данных

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

  • невозможно прочитать данные другого сайта через API;
  • невозможно подменить записи другого origin;
  • невозможно получить список ключей чужого хранилища.

Даже при наличии одинаковой структуры приложения данные остаются строго разделёнными.


Влияние Service Worker и PWA

В приложениях с Service Worker и PWA архитектура хранения не изменяется. Service Worker работает в рамках того же origin и использует те же механизмы доступа к localForage.

Это означает:

  • кэширование и storage остаются изолированными;
  • фоновые процессы не нарушают границы origin;
  • все операции проходят через те же API браузера.

Service Worker расширяет функциональность, но не меняет модель безопасности.


Практическая интерпретация модели изоляции

В реальных приложениях это приводит к следующим свойствам системы хранения:

  • данные всегда локализованы внутри конкретного сайта;
  • невозможно создать «общую базу данных» между доменами;
  • перенос данных возможен только через экспорт/импорт или серверные API;
  • архитектура хранения становится предсказуемой и детерминированной.

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


Ограничения, вытекающие из модели origin

Жёсткая изоляция накладывает несколько архитектурных ограничений:

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

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


Взаимодействие с кросс-доменными сценариями

Любые попытки организовать обмен данными между origin должны опираться на внешние механизмы:

  • HTTP API;
  • postMessage между окнами при наличии разрешённого взаимодействия;
  • Shared Workers в рамках одного origin;
  • серверные промежуточные слои.

localForage в этих сценариях выступает исключительно как локальный слой хранения, не предоставляя средств обхода изоляции.


Архитектурная роль изоляции в приложениях

Изоляция данных по origin формирует предсказуемую модель хранения, которая влияет на архитектуру приложений:

  • каждый фронтенд-инстанс имеет собственное локальное состояние;
  • данные не могут «утечь» за пределы приложения;
  • конфликты между разными системами невозможны на уровне браузера;
  • безопасность усиливается без участия разработчика.

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