Security
Security, settled in advance.
A site that sells, takes bookings and manages customer accounts holds data that isn't yours. JEIKO protects it by default: there is nothing to switch on, so nothing to forget.
Accounts
The most attacked way into a website, and the one that opens the most doors.
- A verified email address is required. An account can only log in once its address is confirmed; sign-ups that are never confirmed are deleted after thirty days.
- Passwords of at least ten characters, refused if they are too common, too close to the user's name, or entirely numeric.
- Two-factor authentication, as you prefer: an authenticator app, a security key or passkey, recovery codes — or, failing that, a six-digit code sent by email.
- A security log: logins, failures, logouts, role changes. After an incident, you know when and from where.
- Active sessions you can see, and a button that really logs you out everywhere.
- Roles rather than one super-user for everyone: each team member, and each AI agent, only gets the rights of their own area.
What comes in, and what goes out
Everything that enters the site is checked before it leaves again — towards your visitors or into your inbox.
- HTML is sanitised when saved: the formatting stays, but
scripttags,on…attributes andjavascript:links are removed. An editor cannot, even by accident, run code in an administrator's browser. - The global CSS is parsed, not copied: imports, fonts and external addresses are refused, and its rules cannot reach the admin panel.
- Public forms are protected against bots: an invisible decoy field, and per-IP limits on bookings, contact forms and cookie consent. The refusal is deliberately vague, so a bot learns nothing from it.
- Image uploads are checked: only a genuine image file is accepted, whatever its extension.
Secrets
A copy of the database — a stray backup, a resold disk — must grant no access. So JEIKO keeps its secrets in three separate places.
- Outside the database: the site's secret key and the database credentials live in the
.env, readable by the site's own account only. - Encrypted in the database: the Stripe key, the webhook secret, the SMTP password, Google or Apple sign-in secrets. The encryption key is derived from the secret key, which is never in the database: stealing the database alone gets you nothing.
- Never stored: AI agent tokens and two-factor codes are only kept as a fingerprint. A token is shown once, when it is created; lost, it is replaced.
Changing the secret key without losing encrypted secrets
# .env
SECRET_KEY=new-key
SECRET_KEY_FALLBACKS=old-key
# then save the Payment and Email screens again,
# and remove SECRET_KEY_FALLBACKS
The server
Each site runs under its own Unix account, with its own database and service. HTTPS is set up at install time, and the security headers follow.
| Protection | Setting | Against |
|---|---|---|
| HTTPS required | redirect, one-year HSTS | Traffic being read or altered |
| No framing | X-Frame-Options: DENY | Clickjacking from a third-party page |
| Strict content type | X-Content-Type-Options: nosniff | A file being run as a script |
| Limited referrer | strict-origin-when-cross-origin | Internal addresses leaking to other sites |
| Cookies | Secure, HttpOnly, SameSite=Lax | Session theft and forged requests |
| Updates | system script outside the site, package checked by fingerprint | A flaw in the site turning into admin access to the server |
The site can only trigger its own update: whatever runs with administrator rights belongs to the system, not to the site. Before a release is applied, the database is backed up; if any step fails, the previous version is restored.
Personal data
GDPR isn't a banner: it's a retention period, a right of access and a right to be forgotten. JEIKO applies them.
- A cookie banner by category, with time-stamped proof of consent and the version of the policy accepted.
- An account's data exported as a single file: profile, addresses, consents, orders, courses, appointments, questionnaires. Never the password, never anyone else's data.
- Erasure on request, with a record of it that no longer holds any personal data.
- Automatic clean-ups: the security log after one year, closed sessions after thirty days, unconfirmed sign-ups after thirty days.
Adjusting the retention periods
# .env — in days
JEIKO_SECURITY_EVENTS_RETENTION_DAYS=365
JEIKO_USER_SESSIONS_RETENTION_DAYS=30
JEIKO_UNVERIFIED_ACCOUNT_TTL_DAYS=30
What remains yours to do
An honest tool also says what it doesn't do.
- A backup off the server. JEIKO backs up the database every day and before each update, on the machine itself. A copy elsewhere protects you against losing the server.
- Updates to the Debian system, which don't depend on JEIKO.
- Choosing the second factor. A code by email protects against a stolen password, not against a compromised mailbox: for an administrator, prefer an app or a security key.