How we keep your labs (and our infra) safe.
student.mlab.sh hosts vulnerable systems on purpose. That makes isolation non-negotiable. Here's exactly how we keep your labs from spilling onto anything real, including each other.
Each student, their own bubble.
Per-student VPN namespace
You connect to a private network slice with its own CIDR. No traffic to other students, ever.
Outbound firewall
Your lab can't reach anything outside the lab itself, no DNS exfil, no callbacks to the internet.
Snapshot reset
Every lab VM rolls back from a clean snapshot on demand. No state leaks between sessions.
Synthetic data only
No real PII anywhere in our datasets. Everything is generated or sourced from public corpora.
Boring choices on purpose.
SSO via mlab.sh, OAuth 2.0 + PKCE
We never see your password. We get a short-lived access token and a user UUID, that's it.
Sessions signed with HMAC-SHA512
Cookie value is signed with a server-side secret. Tampering is detected and rejected immediately.
HTTPS only, HSTS, no downgrades
Strict-Transport-Security with a long max-age. All traffic terminates at our edge.
Strict CSP, no inline scripts
Content Security Policy locks down what can execute. X-Frame-Options denies embedding.
No client-side analytics on logged-in pages
We use server-side counting on public pages. Once you sign in, no third party watches your moves.
Found a bug? Tell us.
We run student.mlab.sh as a learning platform, and we take it as a personal insult when something breaks. If you find a real vulnerability (auth bypass, isolation escape, persistent XSS on a non-lab page, anything that lets you see another student's data), email us.
Don't test against other students. Use your own account. Don't pivot into our production infrastructure from a lab, the firewall stops it, but trying it anyway will get your account suspended.