JavaScript · Advanced level

Advanced level · Module 5: Performance, Security and Accessibility in JavaScript · Lesson 3 of 4

Security: XSS and Untrusted Data

Prevent cross-site scripting, handle untrusted data safely and add a Content Security Policy as a second line of defence.

In this lesson you will

  • Render untrusted data safely
  • Explain and apply a Content Security Policy

Key concepts

cross-site scripting (XSS)textContent vs innerHTMLContent Security Policyuntrusted input

The lesson

Cross-site scripting (XSS) happens when untrusted data — a name typed by a user, a value from an API — is inserted into a page as HTML and contains script. The attacker's code then runs with the user's access.

Treat all external data as untrusted. Insert text with textContent or by creating elements, never by building HTML strings with innerHTML. If HTML must be rendered, sanitise it with a well-maintained library.

A Content Security Policy header such as script-src 'self' tells the browser to run only scripts from your own site, blocking most injected scripts even if a bug slips through.

Step by step

  1. Show an XSS payload in a name field executing through innerHTML.
  2. Fix the rendering with textContent.
  3. Search the codebase for every innerHTML use and review it.
  4. Add a Content Security Policy and test that the page still works.
Step-by-step

Rendering a visitor's comment safely

The steps that stop a comment like <img src=x onerror=…> from running as code in other users' browsers.

  1. Treat it as untrusted

    Anything from a form, URL, storage or API may contain HTML or script, even if it came from your own server.

  2. Validate on the server

    Check length and allowed characters when the comment is submitted, and reject or clean invalid input.

  3. Create elements, not HTML strings

    const p = document.createElement("p"); p.textContent = comment; list.append(p); — never list.innerHTML += comment.

  4. Sanitise only if HTML is required

    If formatted text must be allowed, run it through a maintained sanitiser library with a strict allow-list.

  5. Add a Content Security Policy

    A header such as script-src 'self' blocks injected inline scripts if a mistake slips through.

Result

The comment is displayed exactly as typed — including any < and > characters — and no script it contains can run.

Practice activity

Audit the visit tracker for XSS risks, fix them all and add a Content Security Policy.

Expected result: No untrusted data reaches innerHTML, the payload no longer runs and the CSP is active.

Check your understanding

  1. What is cross-site scripting?

    Show answer

    Injecting script into a page through untrusted data so it runs in other users' browsers.

  2. How does a Content Security Policy help?

    Show answer

    It restricts where scripts may come from, blocking most injected scripts.

Taught live by an instructor — online or in person. Free course lessons are for self-study and do not lead to a certificate — see registration options.