IndexedDB es una API de bajo nivel para el almacenamiento del lado del cliente de cantidades significativas de datos estructurados. Aunque es potente, requiere una cuidadosa consideración de la seguridad, ya que los datos almacenados podrían ser vulnerables a los ataques XSS. El saneamiento adecuado de los datos, los controles de acceso y el cifrado de los datos confidenciales son esenciales cuando se utiliza IndexedDB en aplicaciones web.
IndexedDB es una base de datos transaccional de bajo nivel integrada en el navegador para almacenar grandes cantidades de datos estructurados en el cliente. A diferencia del sencillo modelo de clave-valor de cadenas de Local Storage, guarda objetos y archivos de JavaScript estructurados, admite índices para búsquedas eficientes y agrupa las operaciones en transacciones. Su API es asíncrona y se basa en eventos o promesas, así que las lecturas y escrituras grandes no bloquean el hilo principal. Las cuotas de almacenamiento son mucho mayores que las de Web Storage, a menudo cientos de megabytes o más según el espacio en disco. Como otros almacenamientos del cliente, está particionado por origen, y sustenta las aplicaciones web offline-first, las progressive web apps y cualquier función que necesite un conjunto de datos local consultable.
IndexedDB está sujeto a la política de mismo origen y no se comparte entre orígenes, pero dentro de un origen cualquier script en ejecución puede leerlo y escribirlo por completo, incluido el código inyectado o de terceros. No ofrece cifrado integrado, así que todo lo que se guarda ahí queda en texto plano en el disco del usuario y expuesto a una carga de cross-site scripting que pueda abrir la base de datos y leer cada registro. Como está diseñado para contener mucho más datos que Local Storage, una brecha puede filtrar volúmenes mucho mayores, incluidos datos personales en caché o copias offline de registros. Además, los datos leídos de vuelta desde IndexedDB y renderizados sin sanear son una vía clásica hacia el XSS basado en el DOM.
Guarda solo lo que la aplicación necesite de verdad estando offline, y evita mantener secretos o tokens en bruto en IndexedDB. Si hay que cachear datos sensibles, cífralos en la capa de la aplicación, idealmente con claves derivadas mediante la Web Crypto API y nunca almacenadas junto a los datos. Trata cada valor leído de la base de datos como entrada no confiable: valídalo y codifícalo antes de insertarlo en el DOM. Una Content Security Policy estricta limita qué scripts pueden ejecutarse y alcanzar la base de datos. El papel de cside está en la parte de los scripts de terceros; su proxy híbrido y su análisis de la carga útil pueden detectar y bloquear en tiempo real un script externo que empiece a abrir y exfiltrar el contenido de IndexedDB.
No, no por defecto. IndexedDB guarda los datos en texto plano en el disco del usuario, y cualquier script del origen puede leerlos. Si necesitas confidencialidad, debes cifrar los valores tú mismo en la aplicación, por ejemplo con la Web Crypto API, antes de escribirlos en la base de datos.
Muchos más. Local Storage suele estar limitado a unos 5 a 10 MB por origen, mientras que las cuotas de IndexedDB llegan a menudo a cientos de megabytes o a un porcentaje del disco disponible, lo que lo hace adecuado para conjuntos de datos offline. Esa mayor capacidad también significa que un compromiso puede exponer un volumen de datos mucho mayor.
We answer client-side security questions every day. Bring yours.