Exercise 2: Why "We Use Tokenization" Doesn't Cover Everything — Possible Solution ==================================================================== WHAT TOKENIZATION ACTUALLY PROTECTS ------------------------------ Per this chapter, Stripe's tokenized checkout fields keep raw card numbers off the store's own SERVER - that protection is real, and is exactly what Chapter 5 explained. But this chapter states directly: "That protects the server - it does not automatically protect the browser." WHY A VULNERABLE PLUGIN IS STILL A REAL RISK ------------------------------ Per this chapter, malicious JavaScript injected into a checkout page through an unpatched, vulnerable plugin can read keystrokes or overlay a fake payment form directly in the customer's own browser, BEFORE Stripe.js ever gets a chance to tokenize anything. Since this interception happens client-side, before tokenization occurs, it is entirely unaffected by the fact that the store's own server never sees raw card data - the attacker never needs the server to see it either, they capture it directly from the browser first. WHY THE STORE OWNER'S REASONING IS INCOMPLETE ------------------------------ Per this chapter, this general attack pattern is commonly called a "Magecart-style" attack, and the chapter states plainly that it is "precisely why keeping every plugin patched and vetted matters even more on a store than on an ordinary blog" - tokenization does not make plugin security optional, because the two protect against different attack surfaces (server-side data exposure vs. client-side script injection). WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly distinguishes what tokenization does protect (the server) from what it doesn't (the browser/client-side), and correctly explains the specific mechanism - client-side script injection via a vulnerable plugin - that lets an attacker bypass tokenization's protection entirely.