Try It

Header — how it's signed

Payload — the claims (readable by anyone!)

Signature — proves the issuer signed it

The lesson: a JWT is signed, not encrypted. Anyone holding the token can read every claim — the payload above is just base64, not a secret. The signature only proves it hasn't been tampered with and that the authorization server issued it. Notice the cnf.jkt claim: that's the key thumbprint a sender-constrained token is bound to. See the Bearer vs PoP demo for why that matters.

The lesson: a bearer token is like cash — whoever holds it spends it, so a stolen one grants full access. A sender-constrained token (DPoP) is bound to a private key the client proves it holds on every call. Steal the token and you still fail, because the key never left the legitimate client. This is the web analog of the mobile per-request hash.

The grey checkerboard is attacker.example, framing your bank page beneath a decoy "Claim your prize" layer at ~40% opacity. Click the decoy button — you're really clicking whatever sits at that exact pixel in the frame underneath.

The lesson: clickjacking doesn't forge a request the way CSRF does — it tricks a real, authenticated user into making a real click on a page they can't see. The defense is declarative and server-side: Content-Security-Policy: frame-ancestors (or the older X-Frame-Options) tells the browser which origins, if any, are allowed to frame the page. Set it to 'none' or a specific list and the attacker's iframe never renders your content at all.

You're logged into your bank in one tab (an ambient session cookie). In another tab, attacker.example auto-submits a hidden form to bank.example/transfer?to=attacker&amount=5000. The browser attaches your cookie automatically — that's the whole attack.

The lesson: CSRF doesn't steal anything — it forges a state-changing request and rides on a session the browser attaches automatically. Two independent defenses close it: SameSite=Strict (or Lax) stops the browser from sending the cookie on a cross-site request in the first place; a per-session, per-form CSRF token means the attacker's forged request is missing something it can't guess. Either one alone usually suffices; real deployments often use both.

Imagine this is a comment box on a page that echoes back whatever a user typed. Nothing here is ever actually executed — the "unsafe" panel is a simulation of what raw HTML insertion would do, rendered as inert text.

Unsafe — page does el.innerHTML = comment (simulated, not executed here)

Safe — page does el.textContent = comment (or a templating engine that HTML-encodes)

The lesson: the payload above is identical in both panels — the difference is entirely in how the page inserts it into the DOM. innerHTML (or any raw HTML sink) parses attacker-controlled strings as markup, so a crafted tag's event handler executes as your page's own JavaScript. textContent, an auto-escaping template, or output encoding turns the same string into inert display text. Content-Security-Policy (next page) is the backstop for whatever escaping misses.

Content-Security-Policy header

The lesson: this is a pure client-side parse of the policy string — no real enforcement, just the same directive-matching logic the browser applies. Try deleting 'unsafe-inline' from style-src, or removing https://cdn.example.com from script-src, and watch results flip. A tight CSP (no 'unsafe-inline', no 'unsafe-eval', an explicit allowlist) is the backstop that makes a successful XSS injection inert — the attacker's script tag can exist in the DOM, but the browser refuses to execute it.

Third-party script content

The lesson: Subresource Integrity hash-pins a third-party script at the moment you trust it. Even one byte of tampering — a compromised CDN, a Magecart-style supply-chain injection — changes the hash completely, and the browser will refuse to execute a script whose integrity attribute doesn't match what was actually served. It doesn't stop the tamper from happening upstream; it stops the tampered script from ever running in your users' browsers.

The lesson: this is the web's closest equivalent to a mobile secure enclave. The private key lives inside crypto.subtle's key store rather than in JavaScript-readable memory; the page can ask it to sign things (see the DPoP proof builder on the Try It hub) but can never read the key itself out, even if an XSS payload runs on the page. That's a materially different security property than a key held as a JavaScript string or localStorage value.

This builds a real, cryptographically signed DPoP proof — using the non-extractable key from WebCrypto Keygen — and runs the same four checks an API gateway would.

The lesson: try three tampers and see which check catches each one — flip a character in the signature (breaks check 1), edit htu in the payload without re-signing (breaks check 1 too, since the signature covers the payload), or click "Build & sign" twice and re-paste an old proof (breaks check 4, replay). Regenerating the key and building a new, validly self-signed proof with a different key breaks check 3 — a valid signature alone proves nothing if the key isn't the one the token was bound to.

code_verifier = 'a1B2...' (kept secret)
code_challenge = BASE64URL(SHA256(code_verifier))

The lesson: every FAPI 2.0 control targets a specific channel-crossing moment. Front-channel steps (3, 4, 5) carry only opaque handles and short-lived, single-use codes — never anything an interceptor could redeem alone. Back-channel steps (2, 6, 7) are where the client authenticates itself and where long-lived secrets and bindings actually move.

The lesson: PSD2 defaults to requiring Strong Customer Authentication on every payment — the TRA exemption is opt-in per transaction, and only holds if the real-time risk score and the amount both clear the issuer's bar. A single hard signal (a RAT/malware indicator) vetoes the exemption outright, regardless of how low the amount is. This is the compensating control for the web's missing hardware root of trust: where mobile leans on the enclave key, the web leans on this risk decision firing correctly, every time.