security posture
Six defensive layers between the internet and your data — documented in full, with nothing to install and nothing to take on faith. Every claim on this page can be independently verified, and the panel on the right is your own browser doing exactly that, right now.
requesting…
defence in depth
Security here isn't one wall — it's a sequence of independent ones. An attacker has to beat every layer below, in order, without tripping the monitoring that watches all of them.
All public traffic terminates at a hardened edge before it ever reaches our hardware. Plain HTTP is refused with a redirect, TLS 1.2 is the floor with 1.3 preferred, and traffic is re-encrypted — and the origin certificate re-verified — on the private leg to the server.
The web tier sends a strict Content Security Policy built on default-src none — nothing loads unless explicitly allowed, and no inline code exists anywhere on the site. HSTS instructs browsers to refuse insecure connections for two years. Version banners are suppressed.
Every application runs in an isolated Docker container joined only to the internal networks it needs. Nothing is published directly to the internet; the reverse proxy is the single doorway. Host firewalls default-deny all unsolicited traffic on both servers.
One identity provider fronts every application — there are no per-app passwords to leak. Accounts exist by invitation only, and two-factor authentication is enrolled as part of account creation, not offered as an afterthought. Enrolment and recovery flows carry bot-resistant challenges.
The two sites communicate exclusively across an encrypted WireGuard tunnel with cryptographic peer identity — no passwords, no exposed login surface, forward-secret session keys refreshed every few minutes. Management interfaces exist only on the tunnel and loopback.
The secondary site pulls encrypted backups from the primary nightly — a pull model, so the primary holds no credentials to the backup store and a compromised primary cannot reach its own backups. Snapshots are AES-256 encrypted before leaving the source machine. A third off-site encrypted copy is being provisioned.
identity
Most breaches walk in through authentication. This platform's answer is to have exactly one authentication system — and make it uncompromising.
data & privacy
The honest answers to the questions that matter, stated plainly enough to be held against us.
threat model
No public signup, no per-app passwords, mandatory MFA — a leaked password list has nothing here to match against.
The CSP forbids all inline code and every unlisted origin. A script that isn’t ours has nowhere to run.
frame-ancestors none — this site cannot be embedded inside another page, full stop.
HSTS with a two-year lifetime means browsers refuse plain-HTTP connections outright, even on first click of an old link.
The mesh has no login surface to attack and refreshes forward-secret keys every few minutes. Recorded traffic is worthless later.
Backups are pulled by the secondary. The primary holds no credentials to the backup store — it cannot delete or encrypt its own history.
verification
These three independent scanners audit this site live — each link runs a fresh scan against itzgee.com:
Inspects every security header this site sends — the strict CSP, HSTS, frame and content-type protections.
Deep audit of the TLS configuration — protocol versions, cipher suites, certificate chain and known vulnerabilities.
Mozilla’s scanner, the strictest of the three on Content Security Policy and cross-origin protections.
Prefer the terminal? Inspect the security headers yourself:
curl -sI https://itzgee.com | grep -iE 'strict|security-policy|x-frame|x-content'