Skip to content
Security Lab

Learn.Experiment.Secure.

An interactive laboratory for web security. See how logins, permissions, encryption and untrusted input really behave, side by side with the safe way to build them.

Explore the labsSee how it works

Every experiment is a simulation that runs in your browser. Nothing here touches a real system.

Untrusted side

Input

GET /admin/reports

Signed in as a Viewer

Trusted side

Check

Is a Viewer allowed to see reports?

Result

403 Forbidden

Authentication confirmed who you are. Authorization decided you may not do this.

Trust boundaryAn illustration. Open a lab to try the real experiment.

How the lab works

Every lab follows the same four steps, so once you have finished one, the next feels familiar.

  1. 1Learn

    A short, plain-language explanation of the idea, with the vocabulary you will meet in real projects.

  2. 2Experiment

    Change inputs, roles or keys in a safe simulation and watch what the system does.

  3. 3Compare

    Put a vulnerable approach next to a secure one and see exactly where they behave differently.

  4. 4Challenge

    Solve a guided scenario with hints and feedback, and retry as often as you like.

The first three labs

Each lab pairs a short explanation with a hands-on experiment you can complete in a few minutes.

  • Authentication & Authorization

    AvailableIdentity and accessBeginner

    Who are you, and what are you allowed to do? Follow fictional requests through login, sessions and permission checks.

    What you can try

    • A fictional login simulator with made-up accounts
    • Session validity you can inspect
    • Expired sessions, and what they do to later requests
    • A role and permission matrix
    Open the Authentication & Authorization lab

  • Cryptography

    AvailableCryptographyIntermediate

    Encoding, hashing and encryption look alike but do very different jobs. Watch each one transform the same message.

    What you can try

    • Encoding, hashing and encryption applied to the same input
    • SHA-256 demonstrations
    • AES-GCM encryption and decryption
    • Safe key generation with the Web Crypto API
    Open the Cryptography lab

  • XSS Prevention

    AvailableInput and outputBeginner

    Untrusted input becomes dangerous when it is treated as code. Compare unsafe and safe rendering of the same text.

    What you can try

    • Untrusted input demonstrations
    • Vulnerable and secure rendering, side by side
    • Safe output encoding
    • A visualisation of how the browser renders HTML
    Open the XSS Prevention lab

The catalog at a glance

Three labs and three guided challenges you can use now. Status shows exactly what is ready.

Labs and guided challenges with their category, level and status
NameStatus
LabAuthentication & AuthorizationAvailable
ChallengeAccess DeniedAvailable
LabCryptographyAvailable
ChallengeProtect the SecretAvailable
LabXSS PreventionAvailable
ChallengeSafe Comment BoxAvailable
Open the full catalog

New to security? Start with four ideas

The labs build on a few concepts. You don't need to know them yet: each lab explains them again where they matter.

Trust boundary
The line where data from someone you can't fully trust enters your system. Every check in these labs happens at a boundary.
Authentication and authorization
Authentication asks who you are. Authorization asks what you are allowed to do. A 401 response means the first failed; a 403 means the second did.
Encoding, hashing and encryption
Encoding changes the format and anyone can reverse it. Hashing is one-way. Encryption can be reversed, but only with the key.
Untrusted input
Anything a user, browser or other system sends you. Treat it as data, never as code, and encode it for wherever it is displayed.

Roadmap

Security Lab grows in small, honest steps. Each milestone ships something you can use.

  1. M0

    Foundation

    Design system, catalog structure, lab plans, two languages and two themes.

  2. M1

    Catalog

    The complete experiment catalog and navigation between labs.

  3. M2Current milestone

    Core labs

    Interactive authentication, cryptography and XSS experiments.

  4. M3

    Challenges

    Three guided challenges with hints and feedback.

  5. M4

    Progress and ecosystem

    Completion tracking, a progress overview and Gateway integration.

  6. M5

    Release readiness

    Accessibility, security validation, responsive testing and launch preparation.

Ideas for later labs

Not scheduled yet. These follow once the first three labs and their challenges are solid.

  • Cross-site request forgeryIdea

    Why a logged-in browser can be tricked into sending requests, and how SameSite cookies and tokens help prevent it.

  • Content Security PolicyIdea

    Write a policy, then see which scripts, styles and frames it allows or blocks.

  • CORS in practiceIdea

    What the browser checks before reading a cross-origin response, and what CORS does not protect.

  • Password storageIdea

    Salts, work factors and slow hashing functions such as PBKDF2, scrypt and Argon2.

  • Token pitfallsIdea

    Signed tokens, expiry, audience checks and the mistakes that make them unsafe.

  • Isolated vulnerable appsIdea

    Real vulnerable services, only inside a separate isolated environment. Never on this site.

About this project

Security Lab is part of FM Work, the personal project ecosystem of M Fikri Marzuki. It sits on the Labs planet of the Gateway, next to other hands-on engineering experiments.

The three labs and their guided challenges are interactive now.

Ground rules

  • Simulated, not real

    Every demonstration is a simulation. No real systems, accounts or third-party sites are involved.

  • Runs in your browser

    No account and no server. Experiments run on your device.

  • No secrets saved

    Progress is kept only on this device and never contains passwords, tokens or keys.

  • Markup stays text

    Untrusted markup is displayed as text and is never run on this page.