Developers
Security model
Timber is designed to be secure by default for the small team that runs a site: administrators, editors and read-only users.
The model#
| Concern | How it's handled |
|---|---|
| Accounts | Email + password per person, stored as a password_hash (8+ characters). Three roles: administrator, editor, read-only — see Users & roles |
| Authorization | Every admin request is checked against the role on the server: editors reach only posts and media uploads; read-only users can't submit any change. Screens that expose raw data or secrets are administrators-only |
| Sessions | Cookie timber_session: HttpOnly, SameSite=Lax, Secure on HTTPS. 8 hours idle / 7 days max. Regenerated on login. A password change or disabling an account ends its other sessions |
| Visitors | No session or cookie for visitors, ever |
| CSRF | A per-session token on every admin POST (header or hidden field), compared with hash_equals |
| Brute force | 5 wrong sign-ins per IP in 10 minutes locks login, plus a delay per failure; the same message for a wrong email and a wrong password |
| Public forms | Honeypot, minimum fill time, per-IP rate limit, option whitelists, length caps, file checks |
| Uploads | Extension allow-list, fileinfo MIME must match, 50 MB cap, SVG scanned for scripts, slugified names, never overwritten; the uploads folder can't execute code |
| File access | Paths are realpath-checked to stay inside assets/ or uploads/; the File Manager never writes PHP |
| Internals | data/, inc/, templates/, themes/, _* and dotfiles are blocked by the web server |
| Admin pages | noindex, no-store, frame-deny; robots.txt disallows /padmin/ |
| Secrets | In data/secrets.json, never rendered back, excluded from export |
| Self-check | The dashboard warns if /data/settings.json is downloadable |
Trust boundary#
Administrators are fully trusted: they can publish raw HTML and JavaScript (pages, Blocks, analytics code). Editors can also publish HTML in post bodies, so give that role to people you trust with your readers. Read-only users can't change anything but can read form submissions.
Your responsibilities#
- Use HTTPS.
- Use long passwords (the Generate links in the installer and Users screen make strong ones), and give people the lowest role that does the job.
- Install immediately after uploading — the first visitor to an uninstalled copy owns the site.
- On nginx, add the rules from
_dev/nginx.conf.example. Without themdata/*.jsonis downloadable. - Keep PHP updated and back up regularly.
- Treat
messages.jsonas personal data under privacy law, and remember read-only users can see it. - Disable or delete accounts when people leave.
Reporting a vulnerability#
Please report security issues privately to the maintainers rather than in a public issue, and give them time to fix it. See Open source & contributing.