Front-end security: HTTPS, XSS, CSP and secrets

HTTPS everywhere

HTTPS encrypts the traffic between the browser and the server, so nobody on the same cafe Wi-Fi or on the network in between can read or change it. The padlock means the connection is encrypted and the certificate matches the domain; it does not mean the site is honest. Free certificates (Let's Encrypt) and modern hosts make HTTPS automatic, and many browser features (service workers, location, camera) work only on HTTPS. The Strict-Transport-Security (HSTS) header tells browsers to always use HTTPS for your domain, even when someone types http://.

XSS: cross-site scripting

If attack code runs on your page, it can do anything your page can do: read what users type, send requests as them, change the prices they see, or show a fake login form. In intermediate-3 you saw why innerHTML with user text is dangerous; here is the full defence.

const comment = 'Nice! <img src=x onerror="alert(1)">';

// Unsafe: the browser parses it as HTML and runs onerror
// box.innerHTML = comment;

// Safe: shown as plain text
box.textContent = comment;

// Need some user HTML (bold, links)? Sanitise it with a tested library
import DOMPurify from 'dompurify';
box.innerHTML = DOMPurify.sanitize(userHtml);

• Never pass user data to eval(), new Function(), setTimeout with a string, or document.write().
• Check URLs before putting them in href or src: "javascript:alert(1)" is a link that runs code. Allow only http: and https:.
• Frameworks like React escape text for you, but their escape hatches (dangerouslySetInnerHTML, v-html) bring the danger back.
• The server must also validate and escape data: front-end checks can always be skipped.

Content Security Policy (CSP)

CSP is an HTTP response header that tells the browser which sources of scripts, styles, images and frames are allowed. If an attacker manages to inject a <script>, a strict CSP stops it from running. It is a safety net, not a replacement for escaping.

Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' https://images.example.com; object-src 'none'; frame-ancestors 'none'

• script-src 'self' blocks inline <script> blocks and onclick="..." attributes, so keep JavaScript in .js files (or use nonces, which some frameworks add for you).
• Start with the Content-Security-Policy-Report-Only header: the browser only reports what it would block, so nothing breaks while you tune the policy. Then switch to the real header.
• frame-ancestors 'none' (or 'self') stops clickjacking: an evil site loads your page in an invisible frame and tricks users into clicking your buttons. The older X-Frame-Options: DENY header does a similar job. frame-ancestors does not work in a <meta> tag; send it as a header.

Cookies, CSRF and CORS

Set-Cookie: session=a8f3k2; Path=/; Secure; HttpOnly; SameSite=Lax

• HttpOnly: JavaScript cannot read the cookie, so an XSS bug cannot steal the session.
• Secure: the cookie is sent only over HTTPS.
• SameSite=Lax (or Strict): the cookie is not sent on most requests started by other sites, which blocks most CSRF.
• CSRF (cross-site request forgery): an evil page makes your logged-in browser send a request (like "change my email") to a real site, and the browser attaches your cookie. Defences: SameSite cookies, CSRF tokens in forms, and never changing data with GET requests.
• CORS is a browser rule that lets a server allow other websites to read its responses. It does not protect your server: curl, Postman and scripts ignore CORS completely. Your API still needs real login and permission checks.

Secrets and third-party code

• Each npm package and each <script> from another site runs with full power on your page. Use fewer, well-known ones.
• Commit package-lock.json and install with npm ci, so everyone gets exactly the same versions. Run npm audit to find packages with known security problems, and update them.
• For a script from a CDN, add an integrity="sha384-..." attribute (Subresource Integrity), so the browser refuses a file that was changed.
• Links with target="_blank": modern browsers already treat them as rel="noopener", so the new tab cannot control your page. Adding rel="noopener noreferrer" is still common for old browsers; noreferrer also hides your page address from the other site.