What Is Clickjacking? XSS and CSRF Explained
What clickjacking is, how XSS and CSRF work, and the concrete defences that shut each one down — without the jargon.
Clickjacking is a browser attack that tricks someone into clicking a hidden control on your site — usually by loading your page in an invisible frame under a fake UI. Together with cross-site scripting (XSS) and cross-site request forgery (CSRF), it is one of the three families of bug that still dominate real-world breaches on small and mid-sized sites. Each one has a well-understood, inexpensive defence. This guide explains what they are 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.
