Security

1. Security principles

LisARM follows a defense-in-depth approach with least privilege, secure defaults, and local-first processing to reduce exposure of sensitive communication content.

2. Architecture: local-first by design

LisARM was designed from the ground up with a zero-trust, local-first architecture. Every compliance scan runs inside your browser, while selected authenticated workflows (for example legal escalation and activity events) sync to LisARM servers.

3. No network requests

The extension only makes outbound requests to LisARM APIs required for authenticated workflows. It does not load remote scripts or call unrelated third-party APIs.

4. Minimal permissions

LisARM requests only the permissions it needs to function:

• storage:To persist your custom keyword configuration via Chrome's built-in sync storage.
• scripting: To inject the compliance scanner into supported social-media compose boxes.
• Host permissions (supported social domains): To activate the content script only on supported social pages.

We do not request broad permissions such as <all_urls>, tabs, webRequest, or history.

5. Data storage and encryption boundaries

Custom keyword lists are stored in chrome.storage.sync, which is managed and encrypted by Google as part of your Chrome profile. We have no access to this storage. If you uninstall the extension, all stored data is removed automatically.

Browser-level sync and encryption controls are provided by the browser vendor. We recommend enabling browser account security features such as MFA and device lock policies in enterprise environments.

6. Content script isolation

The content script runs in an isolated world within the Chrome extension sandbox. It reads the DOM of supported social pages to detect the compose box and post button, but cannot access cookies, local storage, or JavaScript variables from the host page.

7. Secure build and runtime posture

We keep runtime dependencies minimal and rely on explicit extension permissions and controlled script execution paths. Remote code loading is not used in the extension.

We recommend organizations verify extension packages before deployment and use managed browser policies where possible.

8. Manifest V3

LisARMis built on Chrome's Manifest V3 platform, which enforces stricter security policies than Manifest V2, including service worker-based background scripts (no persistent background pages) and declarative content script registration.

9. Payments and billing

LisARM does not store card numbers, CVC/CVV, or magnetic-stripe data on company servers. When billing is enabled, checkout is hosted by a payment provider (e.g. Stripe Checkout) so card details stay on the provider's PCI-scoped infrastructure.

Subscription amounts and line items are defined by server-side price configuration (Stripe Price IDs from environment variables), not by client-supplied totals. Webhook deliveries are verified with a signing secret, and each event ID is processed at most once to prevent duplicate fulfillment.

10. Database, secrets, and backups

Application data lives in MongoDB (typically MongoDB Atlas). Connection strings and API secrets belong in a managed environment (for example Vercel project environment variables), not in source control. MongoDB does not provide PostgreSQL-style row-level security; access control is enforced in the application layer using authenticated sessions and scoped queries.

Network access to the database should be restricted using your provider's IP allowlists or private networking features. Enable provider-managed backups with encryption at rest and periodically test restore procedures as part of your own operational checklist.

11. Operational security recommendations

• Use least-privilege access for social media publishing roles.
• Require legal/compliance review workflows for high-risk posts.
• Enforce MFA and device management for all accounts with posting permissions.
• Establish incident response playbooks for accidental disclosure.
• Prefer centralized log retention (host + optional APM) for API errors and structured security lines (see below).

12. Error monitoring and runtime visibility

Server-side failures are emitted to the hosting platform's runtime logs (for example Vercel function logs). API routes use explicit console.error on unexpected errors. For production, we recommend adding a dedicated error tracker (such as Sentry) alongside these logs when operational maturity requires paging and correlation IDs — wire it via env without shipping third-party scripts to end users for core scanning.

13. Authentication lockouts and suspicious sign-in logging

Credential sign-in requests are rate limited per IP before they reach the authentication handler (sliding window; Upstash Redis when configured, otherwise bounded in-memory fallback on the edge). When the limit trips, callers receive HTTP 429 and platform logs may include structured lines tagged [lisarm-security] for downstream SIEM ingestion.

Failed password checks and other denied credential outcomes append immutable events to a MongoDB security_events collection (reason codes are stored for internal investigation only; user-facing messages remain generic).

14. Platform administrator audit trail

Mutations to the abuse blocklist (adding or removing blocked emails or IPs by platform administrators) append tamper-evident records to security_events with the admin's email, coarse client IP metadata when available, and the affected entry — supporting break-glass reviews after account lockdowns or law-enforcement requests.

15. Open to audit

Because LisARM ships as an unpacked extension with readable JavaScript, security teams can audit every line of code before deploying it across their organization. We welcome and encourage security reviews.

16. Incident response and vulnerability disclosure

Operators maintain an internal incident response plan covering detection, containment, eradication, recovery, and post-incident review (database restore procedures are included as an appendix). If you discover a security vulnerability in LisARM, please report it responsibly to support@balogunharold.com. We will acknowledge receipt within 48 hours and work to resolve the issue promptly.

Please include steps to reproduce, expected/actual behavior, and impact assessment. We request responsible disclosure and ask that you avoid public disclosure until remediation is available.

17. Security limitations

No system can guarantee absolute security. LisARM reduces risk but cannot eliminate all compliance or operational risk. Human review, legal judgment, and organizational controls remain essential parts of your security posture.