Security

Reporting a vulnerability

Send it to security@loghq.org. Tell us what you found and how to reproduce it; you do not need a proof-of-concept exploit. We will acknowledge it, and we will not pursue anyone who reports a genuine finding in good faith and does not access other people's data while doing so.

In transit

Everything, including ingestion, is served over TLS. There is no plaintext ingest endpoint.

Accounts

Passwords are hashed with bcrypt and never stored or logged in a recoverable form. Sessions are held in an HttpOnly cookie, so page scripts cannot read them.

Ingest keys

Each project has its own ingest key, and it is the only credential that endpoint accepts. Keys are per project so a leak is contained to one project rather than an account, and you can rotate one from the dashboard at any time. Rotating invalidates the previous key immediately, which is the right trade: a brief gap while you redeploy is better than a window where both keys work.

The honest limits

Worth stating plainly rather than leaving you to infer it. loghq carries no SOC 2 report and no ISO certification. There is no contractual uptime commitment. If your procurement process requires an audited provider, loghq is not one yet.

What we offer instead is that the whole thing is open source and self-hostable. If you cannot send logs to a third party, run it yourself and the question does not arise.

Your side of it

The most common way log data becomes sensitive is that an application writes it there. Scrub credentials, tokens, card numbers and personal identifiers before the line is written. Nothing we can do downstream is as effective as not sending it.