Security

Seq is designed for use in sensitive environments, and we take the security of our users seriously at all stages of software development. Recognizing our own fallibility, we also strive for a secure-by-default mindset, and aim for full transparency when communicating about the security of Seq.

Key points:

• Seq supports any desired level of hardware and network isolation, it can work with or without access to the broader web
• The Seq UI (client) follows industry-standard security practices to prevent attacks, such as script injection
• HTTPS used in data transit
• Passwords and API Keys are encrypted using high-strength cryptographic hash used to record a salted, one-way hash value (continue reading for how we store other sensitive values)
• Authentication and access control follows well-known and tested roles-and-permissions style

👍

Deploying Seq?

Please consult the Deployment Checklist for further relevant information.

Designing for security

In each layer of Seq we strive to create safe defaults.

For example, in the JavaScript front-end, all presentation is rendered using templates that strongly prevent the introduction of script injection. In the implementation of the Server HTTP API, all endpoints deny access unless security demands are both specified at the endpoint, and presented by the client. In our high-performance storage implementation, we use the memory-safe-by-default Rust programming language, and audit as well as extensively test code that needs to turn safety features off.

Encryption and password management

Seq relies on HTTPS communication to secure data in transit. On Windows, this is provided by the Windows HTTP stack; on Docker/Linux, Seq is commonly deployed with a companion Nginx reverse proxy to perform SSL termination.

Users passwords are never stored in Seq. When local username/password authentication is used, a high-strength cryptographic hash is used to record a salted, one-way hash value, preventing any possible password discovery in the incidence of a security breach. API key tokens are stored in the same hashed format.

Internally, where Seq needs to store and later read a sensitive value such as a feed password, strong encryption with the instance's Secret Key is used. On Windows this key is protected using DPAPI and may additionally be protected using filesystem mechanisms. On Docker/Linux, the key is supplied using an environment variable or via a secret key provider.

Authentication and access control

Seq's access control system uses the well-known roles-and-permissions style, with permissions currently including full administrative access, read access to shared, user and log data, write access to shared, user data, and ingestion permissions.

Additionally, per-user log filters can be applied.

Details on permissions required by each endpoint are specified in the Server HTTP API reference.

Vulnerability disclosure and reporting

We maintain a public issue tracker including security-related issues, and (after coordinating with our customers, when necessary), document reported vulnerabilities there.

📘

Contacting us

If you believe you have found a security-relevant issue in Seq, please contact [email protected].

Bug fixes are released promptly; normally, bug fixes will be released for the current minor version of Seq, and taking a security fix will require rolling forward to the latest minor version of the product.

Enabling "air-gap" isolation

Seq is consciously designed to support any desired level of hardware and network isolation. In particular, offline alternatives are provided for all Seq features that would normally require network communication.

For example, Seq Apps can be installed from a local filesystem folder or private NuGet feed, instead of from the public feed.

Outbound network connectivity such as update checking or telemetry is always opt-in.