Security

Last updated: [PUBLISH DATE] · Version: 0.1 (first draft — not yet legally reviewed, not yet published)

Access control

• Admin access requires a verified server-side session check against our own sessions table — it cannot be self-assigned by a customer account.
• Sensitive fields (admin status, credentials) can only be written by application code that explicitly checks for admin privilege on every request — there is no client-facing route that accepts admin status as input, and no signed-in user can grant it to themselves.
• Multi-factor authentication (TOTP) is enforced on administrative accounts.

Data protection in transit and at rest

• All traffic is served over HTTPS/TLS.
• Passwords are hashed with argon2id; never stored in plaintext.
• Temporary/reset credentials are generated with cryptographically secure randomness and compared using constant-time comparison to prevent timing attacks.
• Sign-in sessions use httpOnly, secure cookies, and can be revoked outright (e.g. on password reset).
• Account and server data is held on infrastructure we operate ourselves — a mixture of Linode and other self-hosted infrastructure, exact split/location(s) still being finalized (see the Privacy Policy §5).
• Backup scripts are written and verified end-to-end against real data (dump, encrypt, decrypt, restore, row counts matched) — but they are not yet running on a schedule: no production object-storage bucket or access keys exist yet, so nothing uploads automatically today. This is the single highest-priority item on our pre-launch checklist; see "What's not yet in place" below. Don't rely on this bullet as a live control until it moves out of that section.

Application security

• Input is sanitized against XSS on both client and server.
• Rate limiting applies to authentication and password-reset routes.
• Security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) are set on every response.
• The application container runs as a non-root user.
• Each Minecraft server runs in its own Docker container, isolating it from other users' servers on the same host.

Vulnerability reporting

Found a security issue? Email security@hostable.games. We aim to acknowledge within 3 business days. Please don't publicly disclose before we've had a chance to respond — a fuller responsible-disclosure / bug-bounty policy is not yet written.

Incident response

We maintain an internal Incident Response Plan covering detection, containment, notification, and post-incident review, backed by an internal breach register that records every incident — whether or not it was reportable — for accountability purposes. If a breach affecting your personal data occurs, we'll notify you and, where required, the ICO, without undue delay.

What's not yet in place

In the interest of not overstating our posture:

• Backups are not yet running on a schedule — the scripts are built and verified against real data, but there's no production object-storage bucket, no cron, and no periodic test restore actually happening yet. Confirmed as pre-launch, not an active breach of any commitment, since no customer has been onboarded under a backup SLA — but it's the top item to close before one is.
• We keep an internal audit log of admin actions, email changes, and email verification events, viewable by admins in our own system. This is not an independent third-party audit log, and it isn't tamper-evident beyond ordinary database access controls.
• Stripe payment integration is built and live for several flows (removing ads, domain renewal, one-off ticket payments); the plan/boost catalog checkout is still a frontend mock pending real Stripe product/price configuration.
• Production hosting is a planned mixture of Linode and other self-hosted infrastructure; the exact split and location(s) are not yet finalized.
• There is no dedicated, tracked counter for repeat copyright-infringement notices per account — see the DMCA/Copyright Policy §6.