Web Security Essentials for Frontend Developers

Part 1 - The Frontend Web Security Landscape

Security is not just a backend concern. Because frontend code runs directly on the user's browser, client-side vulnerabilities expose confidential session tokens, allow data theft, deface websites, and compromise entire user accounts.

Every web developer must understand the fundamental attack vectors and defense mechanisms used to build fortified web applications.

Part 2 - Cross-Site Scripting (XSS) & Prevention

Cross-Site Scripting (XSS) occurs when an attacker tricks a web application into executing arbitrary JavaScript code inside a victim's browser.

Three Types of XSS:

Stored XSS: Malicious script is saved permanently in a database (e.g., in a comment field) and executed whenever other users view the page.
Reflected XSS: Injected script is reflected off a web server in an error message, search result, or URL parameter.
DOM-based XSS: The vulnerability exists entirely in client-side code when unsanitized data is written to dangerous DOM sinks (like innerHTML or eval()).

How to Prevent XSS

// DANGEROUS: Executes arbitrary scripts passed in search query!
const query = new URLSearchParams(window.location.search).get('q');
document.getElementById('results').innerHTML = `Search for: ${query}`;

// SAFE: Encodes text safely without evaluating HTML tags
document.getElementById('results').textContent = `Search for: ${query}`;

Part 3 - Cross-Site Request Forgery (CSRF) & SameSite Cookies

CSRF tricks an authenticated victim into submitting unauthorized commands or transactions (such as changing passwords or transferring funds) from an external attacker-controlled website.

Defenses Against CSRF

SameSite Cookies: Modern browsers support SameSite=Lax or SameSite=Strict, preventing authentication cookies from being transmitted during cross-origin requests.
Anti-CSRF Tokens: Cryptographic unpredictable tokens passed in form payloads or custom headers (X-CSRF-Token).

Part 4 - Client-Side Storage: localStorage vs. Cookies

Where should you store sensitive session tokens (like JWTs)?

Storage Mechanism	XSS Vulnerability	CSRF Vulnerability	Recommendation
`localStorage` / `sessionStorage`	HIGH (Any injected script can read all tokens via JS!)	None	Do NOT store sensitive authentication tokens here!
`HttpOnly` Cookie	PROTECTED (JavaScript cannot read the cookie!)	Vulnerable unless paired with SameSite/CSRF tokens	RECOMMENDED for session tokens.

Part 5 - Content Security Policy (CSP)

Content Security Policy (CSP) is an HTTP response header that restricts which scripts, styles, images, and domains your page is allowed to load:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:;

A strict CSP acts as an impenetrable second line of defense — even if an attacker manages to inject a malicious <script> tag, the browser blocks its execution!

Part 6 - CORS (Cross-Origin Resource Sharing) Demystified

By default, browsers enforce the Same-Origin Policy, preventing scripts on domain-a.com from reading data from domain-b.com.

CORS is NOT a security setting on the frontend; it is a server-side header mechanism (Access-Control-Allow-Origin) allowing trusted domains to access API resources. Frontend developers cannot bypass CORS in production through browser code — the API server must explicitly permit the origin!

Part 7 - Frontend Security Checklist

Never use eval() or pass dynamic strings to setTimeout().
Always sanitize user inputs before rendering into the DOM (use textContent or DOMPurify).
Store session credentials in HttpOnly, Secure, SameSite=Strict cookies.
Serve your entire site exclusively over HTTPS.
Implement a strict Content Security Policy (CSP).
Add rel="noopener noreferrer" to all external links (target="_blank") to prevent Tabnabbing attacks.