Security

The safest data is data that is never kept. Unless you choose to save it, a document you check is read in memory and gone when the results are returned, so a document you did not keep cannot be breached because it does not exist. What we do hold — an email address, a password hash, usage counts, your check history, and any document you have asked us to keep, which is stored encrypted under a key derived for your account — is encrypted in transit, kept on servers we control, and reachable only by the people who operate them. Below is how.

Unless you choose to save it, a document is parsed inside the request that carries it and released when the response is sent. It is not written to disk, not placed in a queue, not cached, and not logged. If a check fails, the failure is logged without the document.

Checking runs entirely on our own server. The text is never sent to a language model, a search API, an analytics service, or any other third party. The case-record lookup is a query against a database file on the same machine, not a call out.

If you are signed in and choose to save a document, it is stored encrypted under a key derived for your account, for the retention period you choose, and deleted when that period ends or when you delete it. Separately, if you are signed in we keep a record of each check — the file's name, when it ran and how many findings it had, never its text — which you can switch off in Settings. No document is stored without your choosing it for that document.

All traffic to the site is served over HTTPS. Plain HTTP requests are redirected. Session cookies are marked Secure and HttpOnly, so they are sent only over encrypted connections and cannot be read by scripts in the page.

The service runs on a server in the United States that we administer. The application runs in a container as an unprivileged user, not as root, and listens only on the machine's loopback interface; the only thing exposed to the internet is the web server in front of it, which terminates TLS. The application's data is a set of database files on that machine's disk, readable only by the account the service runs as.

There is no separate database server, no message broker and no scheduler to secure: the account store and the case-record index are single files, which keeps the surface small and the backup simple.

Passwords are stored as salted hashes using a memory-hard algorithm; we cannot read them and do not transmit them. Password reset and verification links are single-use and expire.

Sign-in, sign-up, password reset and verification requests are rate limited per address, and the address is taken from the connection rather than from a header a client could forge. The key that signs sessions and reset links is generated on the server the first time it starts, is stored outside the code, and is never written into the source or the container image.

Sessions expire after seven days. Settings lists every device signed in to the account and lets any of them, or all of them, be signed out. Closing an account deletes it.

Administrators are a fixed list in the source code, not a flag in the database, so nothing that runs at runtime can grant administrative access. An administrator must also hold a confirmed account. The administrative area shows aggregate usage and the state of the case-record index; it has no view of any document.

Access to the server itself is by key, limited to the people who operate it.

Three providers are involved in running the service and none of them sees a document: the company that hosts the server, the email provider that delivers account emails, and the network provider that carries traffic to the site. Account emails are sent from fixed templates; the mailer cannot send an arbitrary message.

The case-record index is built from public bulk data published by the Free Law Project. It is downloaded to our server and queried there. No query about your document leaves the machine.

The checker applies rules written in code. There is no model whose behaviour could drift, and no prompt that a document could inject into. The rules are covered by a large automated test suite, including tests that fail the build if the usage log gains a column that could hold a filename, document text or an IP address, or if an administrative page omits its access check.

Dependencies are pinned, and packages are not allowed to run install-time scripts. The production image is built from a fixed commit before the running service is replaced, so a build that fails leaves the previous version serving.

The web server keeps standard access logs: the requesting address, the path, the time and the browser's self-description. They contain no document content and are rotated after a short period. The application's usage log records counts only, with a visitor identifier that is rehashed daily so records from different days cannot be linked to one person.

If you find a security problem, write to security@counselcite.com with enough detail to reproduce it. We will acknowledge the report within two business days, keep you informed while we fix it, and credit you if you wish. Please give us a reasonable time to fix a problem before publishing it, and do not access data that is not yours while testing.

The privacy policy says what we collect and why. The terms of service say what the service is and where responsibility lies.