O IndexedDB é uma API de baixo nível para o armazenamento client-side de grandes quantidades de dados estruturados. Apesar de poderoso, exige atenção cuidadosa à segurança, já que os dados armazenados podem ficar vulneráveis a ataques de XSS. A sanitização adequada dos dados, os controles de acesso e a criptografia de dados sensíveis são essenciais ao usar o IndexedDB em aplicações web.
O IndexedDB é uma base de dados transacional de baixo nível, integrada no navegador, para armazenar grandes quantidades de dados estruturados no cliente. Ao contrário do modelo simples de chave-valor de texto do Local Storage, guarda objetos JavaScript estruturados e ficheiros, suporta índices para pesquisas eficientes e agrupa operações em transações. A sua API é assíncrona e orientada a eventos ou promises, por isso leituras e escritas grandes não bloqueiam a thread principal. As quotas de armazenamento são muito maiores do que as do Web Storage, muitas vezes centenas de megabytes ou mais, dependendo do espaço em disco. Como o restante armazenamento do cliente, é particionado por origem, e serve de base a aplicações web offline-first, progressive web apps e qualquer funcionalidade que precise de um conjunto de dados local pesquisável.
O IndexedDB está sujeito à política de mesma origem e não é partilhado entre origens, mas dentro de uma origem é totalmente legível e gravável por qualquer script em execução, incluindo código injetado ou third-party. Não oferece encriptação integrada, por isso tudo o que ali é guardado fica em texto simples no disco do utilizador e exposto a um payload de cross-site scripting que consiga abrir a base de dados e ler todos os registos. Como foi concebido para guardar muito mais dados do que o Local Storage, uma violação pode vazar volumes muito maiores, incluindo dados pessoais em cache ou cópias offline de registos. Dados lidos de volta do IndexedDB e apresentados sem higienização são também um caminho clássico para XSS baseado no DOM.
Guarde apenas o que a aplicação realmente precisa offline, e evite manter segredos ou tokens em bruto no IndexedDB. Se dados sensíveis tiverem mesmo de ser colocados em cache, encripte-os na camada da aplicação, idealmente com chaves derivadas através da Web Crypto API e nunca guardadas junto dos dados. Trate cada valor lido da base de dados como entrada não confiável: valide-o e codifique-o antes de o inserir no DOM. Uma Content Security Policy rigorosa limita quais scripts podem correr e chegar à base de dados. O papel da cside é do lado dos scripts third-party; o seu método Script e a análise de payload conseguem detetar e bloquear em tempo real um script externo que comece a abrir e a exfiltrar o conteúdo do IndexedDB.
Não, não por predefinição. O IndexedDB guarda os dados em texto simples no disco do utilizador, e qualquer script na origem consegue lê-los. Se precisar de confidencialidade, tem de encriptar os valores você mesmo na aplicação, por exemplo com a Web Crypto API, antes de os escrever na base de dados.
Muitos mais. O Local Storage costuma estar limitado a cerca de 5 a 10 MB por origem, ao passo que as quotas do IndexedDB chegam habitualmente a centenas de megabytes ou a uma percentagem do disco disponível, o que o torna adequado para conjuntos de dados offline. A maior capacidade também significa que um comprometimento pode expor um volume de dados muito maior.
We answer client-side security questions every day. Bring yours.