Clickjacking, XSS and CSRF: The Web Attacks You Can Stop Today
Three of the most common web attacks explained without the jargon — plus the concrete defences that shut each one down.
Most successful attacks on small and mid-sized websites are not exotic. They are the same three families of bug that have topped the charts for two decades: cross-site scripting, clickjacking and cross-site request forgery. The good news is that each one has a well-understood, inexpensive defence. This guide explains how they work and exactly what to do about them.
Cross-site scripting (XSS)
XSS happens when an attacker manages to run their own JavaScript inside your visitor's browser, in the context of your site. Once their code runs, it can read cookies, capture keystrokes, impersonate the logged-in user and silently steal data. The classic example is a comment box that does not sanitise input — an attacker posts a <script> tag and it executes for everyone who views the page.
- Escape and sanitise all user input before rendering it back into a page.
- Set a Content-Security-Policy that only allows scripts from sources you control — this stops injected scripts from running even if one slips through.
- Use `HttpOnly` cookies so that even successful XSS cannot read your session cookie from JavaScript.
A well-tuned Content-Security-Policy turns XSS from a critical breach into a blocked, logged event. It is the single most effective defence against script injection.
Clickjacking
In a clickjacking attack, your real site is loaded inside an invisible frame on a malicious page. The attacker overlays their own buttons so that when the victim thinks they are clicking 'Play video', they are actually clicking 'Delete account' or 'Confirm payment' on your site, fully logged in. They never see your page — only the trap laid over it.
The defence is to forbid other sites from framing yours. Historically this was done with X-Frame-Options, and the modern equivalent is the frame-ancestors directive inside your Content-Security-Policy.
X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none'
Cross-site request forgery (CSRF)
CSRF tricks a logged-in user's browser into making a request they never intended. Because the browser automatically attaches their session cookie, the request looks completely legitimate to your server. A hidden form on a malicious page can quietly submit a 'change email' request to your site using the victim's active session.
- Use anti-CSRF tokens — a unique, unpredictable value tied to each session that must accompany every state-changing request.
- Set cookies with `SameSite=Lax` or `Strict` so they are not sent on cross-site requests in the first place.
- Require re-authentication for the most sensitive actions, such as changing a password or payment details.
The pattern behind all three
Notice that the same handful of controls keeps appearing: a strict Content-Security-Policy, correctly configured cookies, and validating that requests are genuine. These are not large engineering projects — they are configuration. Most sites are exposed not because the fixes are hard, but because nobody has checked whether the defences are actually in place.
A scan tells you, header by header, which of these defences are active on your live site and which are missing — then gives you the exact configuration to close the gaps.
You do not need a security team to shut down the most common attacks on the web. You need to know your current state and apply a short, well-understood checklist. Scan your site, fix the gaps it surfaces, and you will have neutralised the threats that account for the overwhelming majority of real-world breaches.
