Text versus markup: innerHTML parses, textContent doesn't
The user's text created real <b> and <i> elements through innerHTML. Bold text is harmless, but it proves the browser obeyed the user's markup, and the same path could carry code. With textContent or escaping, it stays visible text. & is escaped first so the other entities aren't double-escaped.
Most front-end security bugs come from treating untrusted text as code: prevent XSS by keeping data as text (textContent, safe DOM APIs, escaping, URL checks), limit the damage with a Content Security Policy, block CSRF with SameSite cookies and tokens, and treat every third-party script as code with full access to your page.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Rewrite this safely: card.innerHTML = "<h3>" + user.name + "</h3><p>" + user.bio + "</p>";.
Write isSafeImageUrl(input) that accepts only https: URLs on your own host img.hectal.example.
Write the response headers for a session cookie and a strict CSP for a page that loads only /app.js with a nonce.
Explain it without notes
What is XSS, and what are the main ways to prevent it in front-end code?
What is the difference between stored, reflected and DOM-based XSS?
What does a Content Security Policy do, and how would you roll one out safely?
What is CSRF and how do SameSite cookies and tokens stop it?
How do you reduce the risk of third-party scripts?
Preview
Console
Nothing logged yet.Expected console output
elements from innerHTML: 2
elements from textContent: 0
Great post! <b>Loved</b> it <i>a lot</i>
elements after escaping: 1