Security

A wiki holds a lot of what a team knows: plans, decisions, how things are done, sometimes things that must stay private. This page explains how Tesria protects it, what it relies on you to do, and how to tell us if you find a weakness.

It is written for anyone who wants to know. If you run a Tesria that people will reach from the internet, also work through Security hardening before you open it up.

Who can see what

• Every request is checked. Whether it comes from the browser, a script or an assistant, Tesria checks the space’s permissions and the page’s restrictions before it answers.

• What you may not see does not exist. A page you are not allowed to see answers “not found”, the same as one that was never written, so nobody can find out it is there by guessing.

• Nothing leaks around the side. Search, notifications, live content, exports and the admin dashboard only ever show what the person looking may see.

• Nothing is public by accident. Reading without an account needs two switches, one for the whole wiki and one for the space, and publishing a space alerts every administrator.

Signing in

• Passwords are never stored, only a fingerprint made with Argon2id, a method designed to make guessing slow and expensive even for someone who steals the database.

• Guessing is slowed down. After 5 wrong passwords, an account is locked for a minute, doubling up to 15 minutes; and each address may only try 10 times a minute. Both are adjustable, and never permanent, so nobody can lock someone else out for good.

• Two-factor sign-in, with a code from a phone app and single-use recovery codes, for anyone who wants it. Administrators can be required to use it.

• Single sign-on with your organization’s own sign-in service, if you set it up.

Staying signed in safely

• Sessions end. After 14 days without use, and after 90 days however much it is used, a session signs out.

• You can see and end each one. Your profile lists every device where you are signed in; sign out any of them. Changing your password signs out all the others.

• An unattended browser cannot do the worst things. Administration that is hard to undo, such as changing roles, asks for your password again unless you signed in within the last 5 minutes. Deleting a space or restoring a backup asks for it every time.

Your data on the server

• Encrypted on the way. Everything you do in Tesria goes over HTTPS, and the sign-in cookie is marked so that a browser never sends it without HTTPS.

• Secrets are kept secret. API tokens are stored only as fingerprints and shown once; the mail server password and two-factor secrets are stored encrypted.

• Backups are encrypted. The continuous database backups always are, and every offsite copy is encrypted with its own passphrase before it leaves the server.

• Nothing is sent to us. Tesria does not report to anyone. It only sends what you set up: email, offsite backups and webhooks.

Limits on what content can do

• Uploaded files cannot act as the site. A file someone attaches is served so that a browser will not run it as part of Tesria.

• Your network stays yours. Webhooks and link previews cannot reach private addresses, such as the server itself or other machines on your network, so a wiki page cannot be used to probe them.

• Only allowed sites are embedded. Pages can show videos and designs only from sites on the wiki’s allowed list.

• The browser is told what to trust. Tesria sends the security headers that stop other sites from framing it and stop injected scripts from running.

Watching for trouble

• Alerts. Every administrator is told, in the bell and by email once email is set up, about bursts of failed sign-ins, many accounts tried from one address, many pages removed quickly, a new administrator, a failed or overdue backup, and more. See Security (administration).

• Blocking. An administrator can block an address straight from an alert, or a whole range of addresses, in Admin, Security (Admin is in the top bar; in a narrower window it is under More, and on a phone in the ☰ menu).

• An audit log that cannot be quietly changed. Every administrative change is recorded, and each entry is chained to the one before, so editing or deleting one breaks the chain and is detected. Tesria itself runs with database access that cannot change the log, and every entry is also written to the server’s own log.

What Tesria cannot protect against

Some things are outside what any application can defend, and are the job of whoever runs the server:

• A compromised server. Someone who controls the machine Tesria runs on controls Tesria.

• An administrator who means harm. Administrators are trusted by design. What they do is recorded in the audit log, and the owner decides what each role may do.

• A flood of traffic. Stopping an attack by sheer volume is the network’s job.

Your part: keep Tesria up to date (Upgrading), turn on two-factor for every administrator, keep an offsite copy of the backups, and, before letting the internet in, work through Security hardening.

Reporting a vulnerability

If you find a way around any of the above, please tell us privately first, so it can be fixed before anyone else learns of it. A weakness in Tesria is a weakness in every Tesria someone runs.

1. Report it privately, never in a public issue or post. Use GitHub’s private vulnerability reporting on the Tesria repository, or the contact in its SECURITY.md file.

2. Include what you found, how to reproduce it, the version (Administration, About shows it), and what you think the impact is.

3. Test only on your own Tesria. A proof of concept against your own instance is welcome; against anyone else’s it is not.

You can expect an acknowledgement within a few days, a fix or a way to avoid the problem as fast as its severity warrants, and credit in the changelog unless you would rather not. Please give a fix a reasonable head start before writing about it.