Security

Telling us about a problem

Write to [email protected]. Say what you found and how to make it happen, and give the version number from the corner of any page in the app.

There is no public tracker, so nothing you send is published while it is being looked at. If it turns out to be real, the fix goes into the next release and the what's new page says what changed.

Where your secrets are kept

Your password is never stored. Only a hash of it is, and a hash cannot be turned back into the password.

Your TMDB key and your mail password are encrypted before they go into the database. The key that encrypts them sits beside the database as secret.key, readable only by the user the app runs as. The login cookie is signed with a second key, session.key, kept the same way.

None of it is in the compose file, in an environment variable or in a config file. Everything is typed into the Settings page inside the app.

How the container runs

As user 1000, never as root, and it only ever writes to the one directory you mounted. The compose file in the project goes further and is worth copying:

security_opt:
  - no-new-privileges:true
cap_drop:
  - ALL
read_only: true
tmpfs:
  - /tmp

That drops every Linux capability, stops the process ever gaining new privileges, and makes everything except your data directory and a small /tmp read only.

The login cookie

One cookie, signed, marked HttpOnly so no script can read it, and SameSite Lax so another site cannot ride on it. It holds nothing but the fact that you are signed in.

Set NEXTUP_HTTPS_ONLY=1 when every way in really is HTTPS and the cookie is marked Secure as well, which stops a browser ever sending it over plain HTTP. Leave it off if you still reach the container directly on something like 127.0.0.1:4090, or you will not be able to sign in.

What it does not do

Worth knowing before you decide where to put it.

• One account, no second user, and no two-factor.
• Only a simple limit on password guesses: eight wrong ones from one address pause sign-in for fifteen minutes. The count lives in memory, so a restart clears it, and behind a proxy every visitor shares the proxy's address. A weak password on an open address would still be guessed in the end.
• No audit log of who signed in and when.

Where to put it

On your own network, or on a tailnet, is the easy answer. Nextup is a notebook for one person and does not need to be on the public internet at all.

If something does sit in front of it, bind the container to this machine only and let the proxy be the one listening:

ports:
  - "127.0.0.1:4090:8080"

Then give the proxy a certificate, set NEXTUP_HTTPS_ONLY=1, and change the password from the one it ships with.

Which versions get fixes

The newest one. There is a single line of releases and no long-term branch, so a fix goes into the next version and nowhere else. Updating is two commands and your data is untouched, so there is little reason to sit on an old one.