IndexedDB is een low-level API voor client-side opslag van aanzienlijke hoeveelheden gestructureerde gegevens. Hoewel krachtig, vereist het zorgvuldige beveiligingsoverweging aangezien opgeslagen gegevens kwetsbaar kunnen zijn voor XSS-aanvallen. Juiste gegevenssanering, toegangscontroles en versleuteling van gevoelige gegevens zijn essentieel bij het gebruik van IndexedDB in webapplicaties.
IndexedDB is een low-level, transactionele database die in de browser is ingebouwd voor het opslaan van grote hoeveelheden gestructureerde data aan de clientkant. Anders dan het eenvoudige string-sleutel-waardemodel van Local Storage bevat het gestructureerde JavaScript-objecten en bestanden, ondersteunt het indexen voor efficiënte opzoekingen en groepeert het bewerkingen in transacties. De API is asynchroon en event- of promise-gedreven, zodat grote lees- en schrijfbewerkingen de hoofdthread niet blokkeren. De opslagquota zijn veel groter dan die van Web Storage, vaak honderden megabytes of meer, afhankelijk van de schijfruimte. Net als andere clientopslag is het opgesplitst per origin, en het vormt de basis voor offline-first webapps, progressive web apps en elke functie die een doorzoekbare lokale dataset nodig heeft.
IndexedDB is gebonden aan het same-origin policy en wordt niet gedeeld tussen origins, maar binnen een origin is het volledig leesbaar en schrijfbaar door elk uitvoerend script, inclusief geïnjecteerde of third-party code. Het biedt geen ingebouwde versleuteling, dus alles wat daar wordt opgeslagen staat in platte tekst op de schijf van de gebruiker en is blootgesteld aan een cross-site scripting-payload die de database kan openen en elk record kan lezen. Omdat het ontworpen is om veel meer data te bevatten dan Local Storage, kan een inbreuk veel grotere volumes lekken, waaronder gecachte persoonsgegevens of offline kopieën van records. Data die uit IndexedDB wordt teruggelezen en zonder ontsmetting wordt weergegeven is ook een klassieke route naar DOM-gebaseerde XSS.
Sla alleen op wat de applicatie werkelijk offline nodig heeft, en vermijd het bewaren van ruwe geheimen of tokens in IndexedDB. Als gevoelige data toch gecacht moet worden, versleutel het dan in de applicatielaag, idealiter met sleutels die via de Web Crypto API zijn afgeleid en nooit naast de data worden bewaard. Behandel elke waarde die je uit de database leest als onvertrouwde invoer: valideer het en encodeer het voordat je het in de DOM invoegt. Een strikt Content Security Policy beperkt welke scripts mogen draaien en de database kunnen bereiken. cside's rol ligt aan de kant van de third-party scripts; de Script-methode en payload-analyse kunnen een extern script detecteren en blokkeren dat de inhoud van IndexedDB begint te openen en in realtime naar buiten sluist.
Nee, niet standaard. IndexedDB slaat data in platte tekst op de schijf van de gebruiker op, en elk script op de origin kan het lezen. Als je vertrouwelijkheid nodig hebt, moet je de waarden zelf in de applicatie versleutelen, bijvoorbeeld met de Web Crypto API, voordat je ze naar de database schrijft.
Veel meer. Local Storage is doorgaans begrensd op rond de 5 tot 10 MB per origin, terwijl de quota van IndexedDB vaak oplopen tot honderden megabytes of een percentage van de beschikbare schijf, waardoor het geschikt is voor offline datasets. De grotere capaciteit betekent ook dat een compromittering een veel groter volume aan data kan blootstellen.
We answer client-side security questions every day. Bring yours.