Security at AnoLawg

Law firms hold privileged client data. Here’s how we protect it — and how to reach us if you find something we missed.

How we protect your data

Encryption in transit

Production browser, API, webhook, and background-job traffic is served over HTTPS with modern TLS termination through our hosting provider.

Encryption at rest

Managed database and object-storage providers encrypt persisted data at rest. Client-portal chat payloads are additionally end-to-end encrypted where the encrypted channel state is active.

Password policy

Passwords are hashed with Node's built-in scrypt memory-hard KDF and a per-user salt. We never store plaintext passwords, and firm password-strength rules can raise the default requirements.

Session management

Sessions are stored server-side in Postgres and referenced by an httpOnly, Secure, SameSite=Lax cookie in production. Standard sessions expire after 7 days by default; webmaster sessions have shorter step-up controls.

Multi-factor authentication

MFA is required for Webmaster accounts and supported for enrolled users through TOTP authenticator apps and single-use recovery codes. Webmaster-sensitive routes require a current MFA step-up.

Penetration testing

Security reviews are tracked in the launch and cleanup roadmaps. Independent third-party penetration testing is planned before broad production rollout and after significant architectural changes.

Incident response

We maintain internal incident runbooks and escalation paths. Confirmed incidents affecting customer data are assessed for legal notice obligations and disclosed to firm admins within applicable legal timelines.

Least privilege & audit

Privileged application access is limited to named webmaster/support users and gated by MFA where required. Sensitive actions such as billing changes, impersonation, exports, retention holds, and permission changes write audit records.

Infrastructure & certifications

We rely on audited subprocessors for the parts of the stack where certification is the bar. See our DPA for the full list.

Payments by Stripe

PCI DSS Level 1

Card data never touches our servers. Stripe Checkout and the Stripe Customer Portal handle all payment flows.

Hosted on Vercel

SOC 2 Type II · ISO 27001

Our compute and edge network inherit Vercel's audited controls. See vercel.com/security for their current reports.

Postgres by Neon

SOC 2 Type II

Primary database is managed Postgres on Neon, with encrypted backups and point-in-time recovery.

SOC 2 Type I

In progress — target 2026

AnoLawg is pursuing its own SOC 2 Type I attestation. Contact security@anolawg.com for status.

Privileged communications

Messages sent through a matter’s Client Portal channel and messages sent through an accepted referral channel are treated as attorney-client privileged by default. Privilege is a legal doctrine, not a technical guarantee, but the application marks those records so support and export flows can apply stricter controls. On the wire they carry aprivilegedmetadata flag; in our database the mirror columnClientMessage.privilegeddefaults to true for every matter-client row. Colleague DMs and informal group chats are not flagged as privileged unless the conversation is matter-scoped.

The flag drives two enforcement points that limit AnoLawg’s own access to your communications:

  • Webmaster impersonation. An AnoLawg webmaster can impersonate a firm user for support and incident response, but impersonation into a privileged channel requires an extra written reason and an attached legal-review flag in the audit record. Without both, the authorization check rejects the session at the chat layer.
  • Firm-scoped message exports. Exports initiated by a webmaster or firm admin redact rows whereprivileged = trueunless the export is accompanied by an explicit client-consent record naming the matter and scope.

Every impersonation and every export — privileged or not — writes an immutable audit row with actor, target, reason, and the legal-review flag when applicable. Firm admins can review those records on request.

Responsible disclosure

Found a vulnerability? Thank you — please report it so we can protect our customers and their clients. We acknowledge researchers publicly (with your permission) and commit to the response times below.

Bug bounty

AnoLawg does not currently offer monetary rewards for vulnerability reports. We run an informal recognition program: qualifying reports earn a public acknowledgment on this page (with your permission), a thank-you from the team, and a direct line to the engineer who fixed the issue.

We may formalize this into a paid program (e.g. via HackerOne or Bugcrowd) as AnoLawg grows. Until then, the informal policy applies: in-scope reports that meet the scope rules and include a working proof-of-concept will be triaged, fixed, and credited. We do not currently pay bounties, swag, or referral fees — please do not ask for them as a condition of disclosure.

Researchers acting in good faith under this policy are covered by the safe-harbor terms below.

How to report

Email us with as much detail as you can. PGP/S-MIME is optional; plain email is fine for initial contact and we’ll arrange an encrypted channel if the report warrants one. We do not publish a security contact encryption key yet, so the current security.txt record intentionally omits an Encryption field.

Machine-readable record
/.well-known/security.txt (RFC 9116)

Scope

In scope

  • anolawg.com and all subdomains
  • The AnoLawg web application (CRM, Client Portal, public profiles, Webmaster Portal)
  • API endpoints under /api/*
  • The public /.well-known/security.txt record

Out of scope

  • Denial-of-service attacks (network, application, or resource exhaustion)
  • Physical attacks, social engineering of staff, or phishing AnoLawg customers
  • Automated scanner output without a working proof-of-concept
  • Vulnerabilities in third-party services we rely on — report those to the vendor
  • Missing best-practice HTTP headers with no exploitable impact

What a good report looks like

  • A clear description of the vulnerability and its impact
  • Step-by-step reproduction: URLs, payloads, HTTP requests, affected accounts
  • Your testing environment (browser, OS) and the date/time of testing
  • Any screenshots, logs, or proof-of-concept code
  • Your preferred name/handle for the acknowledgments list (or request to remain anonymous)

Response process

  1. 1Report arrives at security@anolawg.com or through /.well-known/security.txt.
  2. 2We acknowledge within 48 hours and assign an internal tracking ID.
  3. 3We validate impact, affected systems, and exploitability within 5 business days.
  4. 4We prioritize remediation based on severity and notify affected customers when required.
  5. 5We confirm the fix with the reporter and, with permission, add an acknowledgment.

Acknowledgment within 48 hours

We will confirm receipt by email, assign an internal tracking ID, and tell you who is coordinating the response.

Triage update within 5 business days

We will confirm whether the issue is reproducible, classify severity, and share the next remediation or follow-up step.

Coordinated disclosure

We ask researchers to give us reasonable time to remediate before public disclosure, and we will keep you updated as the fix progresses.

Safe harbor

We consider security research conducted under this policy to be authorized and in good faith. If you follow the rules below, we will not pursue civil or criminal action, initiate a complaint to law enforcement, or support third-party legal action against you for the research itself.

  • Make a good-faith effort to avoid privacy violations, data destruction, or disruption of service
  • Only interact with accounts you own or have explicit permission to access
  • Give us reasonable time to remediate before any public disclosure
  • Stop testing and notify us immediately if you encounter customer data, credentials, privileged communications, or production secrets

Safe harbor does not cover extortion, threats, persistence, destructive testing, social engineering, denial-of-service activity, or access to data beyond what is necessary to prove the issue.

Acknowledgments

We publicly thank researchers whose reports led to a fix, with their permission. Once we start receiving reports, this section will list names (or handles) and a short description of each fixed issue.

Want to be listed? Let us know in your report how you’d like to be credited. We’ll always respect requests to remain anonymous.

Related