Local-first security review

Cybersecurity posture for the risk assessment ecosystem

This page documents the security model, known design risks, browser storage behaviour and practical hardening steps for using the Risk Assessor and Risk Configurator with minimal exposure.

Infrastructure/Architecture

The ecosystem is intentionally simple: static HTML applications, local JSON configuration packs and browser-based import/export. There is no application server, identity provider, database or background service in the normal workflow.

Runtime model

Risk-assessor.html and Risk-configurator.html execute entirely in the user's browser. They can be opened from disk or served from a trusted internal web server.

Data flow

Users load or create JSON configs, answer assessment questions, and export JSON, CSV, Markdown or print/PDF reports. Files are controlled by the user.

Configuration packs

Bundled packs live in configs/. A bundled JavaScript file is used so templates can load from file://, where browsers restrict direct file reads.

Optional AI connections

AI features call the configured provider endpoint directly from the browser using the user's API key. This is the main intentional network path.

Security boundary: the browser profile and local device are the trust boundary. Anyone or anything with access to that browser profile, downloaded files, clipboard or local folder may be able to access assessment content.

Key Known Vulnerabilities Coming From The Design

Area	Design risk	Practical control
Local-only app	No server-side authentication, access control, central logging or central data loss prevention. Protection depends on endpoint and browser controls.	Use on managed devices, encrypted drives and approved folders. Do not place sensitive exports in unmanaged sync locations.
Browser storage	Autosaved assessments and configurator state persist in local storage and can remain after the tab is closed.	Turn autosave off for highly sensitive work, use Clear storage, and run in a dedicated browser profile.
Imported JSON	Configs and saved sessions are user-supplied input. Malicious or corrupted files could manipulate displayed content, scoring logic or AI prompts.	Only open configs from trusted sources. Review changes, validate configs, and keep golden packs read-only.
DOM rendering	The apps render rich content in the browser. Although much app output is escaped, any missed escaping path could become script injection if hostile config text is loaded.	Treat unknown configs as untrusted. Prefer a hardened browser profile without extensions and with no active sensitive sessions.
AI API use	Assessment data, evidence text and prompts can be sent to external AI endpoints. Browser-side keys are visible to the page runtime while the tab is open.	Use approved AI providers only, use low-privilege spend-capped keys, avoid restricted data, and clear the session key when finished.
Distribution integrity	The ZIP and local HTML files are not protected by a built-in signature or hash check.	Distribute via trusted channels, publish checksums, keep a known-good master copy and scan the ZIP before use.
Browser extensions	Extensions with page access may read page content, form fields, local storage, clipboard actions or generated reports.	Use a clean profile or enterprise policy to disable unnecessary extensions for assessment work.

Data Storage/Session Storage

The apps minimise backend exposure by keeping data in the browser and in user-downloaded files. That reduces server risk, but increases the importance of local device hygiene.

Local storage

riskAssessorAutosave and riskConfiguratorAutosave can store current work between sessions. Guided-help preferences and AI provider, endpoint and model settings also persist locally.

Session storage

AI API keys are stored separately in sessionStorage, so they are cleared when the tab or browser session closes. They still exist in the browser while the tab is active.

Exported files

Saved sessions and reports can include project metadata, answers, evidence references, notes, controls, custom controls, AI output and embedded configuration data.

Clipboard

Copying AI packages or report text places assessment content on the operating system clipboard, where other apps or clipboard history tools may retain it.

For sensitive assessments, consider exported session files and reports as confidential records. Classify, store, retain and dispose of them under the same rules as the system evidence used to answer the assessment.

Browser Hardening Guide To Minimise The Inherent Risk

Use a dedicated browser profileKeep the toolkit separate from email, banking, admin portals and privileged SaaS sessions.

Disable unnecessary extensionsExtensions are often the weakest part of a browser trust model. Use only managed, approved extensions.

Prefer a trusted local folderRun the app from a known-good folder. Avoid opening copies from email attachments or random downloads.

Use managed endpoint controlsKeep the operating system and browser patched. Use disk encryption, malware protection and screen-lock policies.

Control AI accessUse organisation-approved endpoints, low-privilege API keys, provider logging controls and explicit data-classification rules.

Clear state after sensitive workUse the app's Clear storage control, close the tab, and remove temporary downloads when the assessment is complete.

Validate before relyingRun the configurator validation checks and review imported configs before using scores for formal governance decisions.

Protect exportsStore session and report files in approved locations with access control, retention and backup rules.

Conclusion/Best Practices

The toolkit is low-infrastructure and local-first, which removes many web-platform risks such as exposed databases and server-side accounts. The trade-off is that the endpoint, browser profile, imported files and optional AI endpoint become the main security controls.

Do

Use trusted copies of the ZIP, HTML files and config packs.
Keep assessments in an encrypted, access-controlled folder.
Use autosave only when local persistence is acceptable.
Clear storage after confidential work.
Review AI prompts and outputs before trusting or sharing them.
Use a clean browser profile for sensitive or client-facing assessments.

Avoid

Opening configs, sessions or ZIP files from unknown sources.
Pasting secrets, credentials or restricted evidence into AI features.
Using personal API keys or unapproved AI endpoints for work data.
Leaving exported reports in Downloads, email attachments or unmanaged cloud sync folders.
Running the toolkit in a browser profile full of untrusted extensions.
Treating generated scores as a substitute for human risk review.