Security & vulnerability reporting

Reporting a problem

Send security reports to communications@utahbar.org. This is the Utah State Bar's general communications address. It is not a dedicated security mailbox and is not described here as continuously monitored.

Published reporting policy URL: https://original-legalresourcemap.lovable.app/security. The same values are published in machine-readable form at /.well-known/security.txt.

No safe-harbor or authorization commitment is made on this page, and no acknowledgement or response time is promised. Any legal safe-harbor language must be drafted and approved by counsel before it is published.

Protections currently in place

• Row-level security is enabled and deny-by-default on application tables.
• Administrative actions are authorized on the server against a separate roles table; the browser cannot grant itself a role.
• Administrator accounts are created by invitation only; there is no public sign-up.
• Administrator sign-in requires a time-based one-time passcode (TOTP) from an authenticator app in addition to a password. Server-side privileged actions fail closed unless the session has completed that second factor.
• Administrator password attempts run through a server-controlled path with a deny-by-default database throttle keyed by a one-way digest of the account identifier. No email address, password, IP address or browser fingerprint is stored for throttling, and error messages are generic so accounts cannot be enumerated.
• Response headers set an enforcing Content-Security-Policy (no report-only mode), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a restrictive Permissions-Policy, and clickjacking protection via frame-ancestors 'none' plus X-Frame-Options: DENY.
• The public usage counter is allowlisted, size-capped and rate-limited.
• Coarse usage records and search submissions are deleted after 30 days by a scheduled database job. Chat text is never stored.

External CAPTCHA (Cloudflare Turnstile) is not enabled today. A verification hook exists in the sign-in path and activates only when the operator supplies a secret key; until then it is not claimed as a protection.

Scope of the sign-in throttle. Our administrator sign-in screen always submits through a server-controlled path that applies attempt limits and automation checks. That is an application-level control: the hosted authentication API is itself a public endpoint, so requests made directly to it, outside this site, are governed by the authentication provider’s own rate limiting and CAPTCHA settings rather than by our throttle. We state this scope plainly rather than overstating the protection.