Clickjacking, CORS Misconfiguration and CSRF: Logic Bugs Scans Catch
Clickjacking, CORS misconfigurations and CSRF are the classic web logic bugs — individually moderate, devastating in combination. Here's how each works and how scanning catches them.
Some of the most reliable attacks on the web require no memory corruption and no exotic payload classes. They abuse the browser's own security model: how pages may be framed, how origins may read each other's responses, and how state-changing requests are authorized. Clickjacking, CORS misconfigurations, and CSRF are the three classics in this family — individually often rated medium, but regularly chained into account takeover. This guide explains each mechanism and how a scanner proves it.
Clickjacking: When Your Page Is the Weapon
The attack. If your site can be embedded in an <iframe> on an attacker's domain, the attacker can overlay invisible UI elements on top of your page ("clickjacking"). The victim thinks they are clicking a button on the attacker's page; they are actually clicking "Transfer funds" on your bank page, or liking a page, or granting an OAuth permission. The browser happily sends your site's cookies along, because as far as it is concerned the victim is interacting with your authenticated page.
The defense. Refuse to be framed, via a response header. X-Frame-Options: DENY (legacy but universally respected) or the modern Content-Security-Policy: frame-ancestors 'none'. One header, whole attack class eliminated.
How scanning proves it. The check is a framability proof: load the target page in a real browser inside an iframe on a neutral origin and record whether the page renders. Guessing from headers alone gets it wrong — legacy headers, header order, and browser-specific behavior make header presence an unreliable signal. A browser-level proof settles the question with evidence.
CORS Misconfiguration: When Reflection Becomes Data Theft
The attack. The Same-Origin Policy stops evil.com from reading responses from bank.com. CORS is the legitimate mechanism for relaxing that — and when configured sloppily, it hands attackers a read primitive. The two dangerous patterns:
- Reflected origins with credentials: the server echoes back any
Originheader inAccess-Control-Allow-OriginwhileAccess-Control-Allow-Credentials: true. Now any origin can make authenticated requests and read the responses — the victim's session data, API responses, everything. nullorigin trust: acceptingOrigin: null(produced by sandboxed iframes and certain redirects) opens the same door via a forged context.
How scanning proves it. An origin matrix: request the resource with a series of controlled origins (attacker-controlled subdomain patterns, arbitrary origins, null), and inspect exactly what the server reflects and whether credentials are allowed alongside. The verdict distinguishes wildcard without credentials (usually acceptable for public resources) from reflected origin with credentials (critical) — because the difference between the two is the difference between a hardening note and a data breach.
The fix. Never reflect arbitrary origins. Maintain an explicit allowlist, emit Vary: Origin, and only enable credentials for origins you control.
CSRF: Borrowing the Victim's Session
The attack. The browser attaches session cookies to requests automatically, regardless of who initiated them. If bank.com/transfer changes state on a plain POST with no secondary verification, an attacker page can silently submit that form while the victim is logged in. The victim never sees anything.
The defense. Anti-forgery tokens (per-session tokens validated server-side), SameSite=Lax|Strict cookie attributes (now the first line of defense), re-authentication for sensitive actions, and Origin/Referer validation as defense in depth.
How scanning approaches it. The scanner examines state-changing forms for token presence, checks cookie SameSite attributes, and evaluates whether sensitive endpoints accept cross-origin requests without origin validation. On authenticated scans (opt-in), it verifies that state changes actually require the token — proving enforcement rather than mere presence.
The Combinations That Hurt
These three bugs are force multipliers for each other:
- Clickjacking + permissive UI: a framable settings page turns any "save" button into a victim-executed action
- CORS reflection + an IDOR: the CORS flaw becomes the exfiltration channel for broken-authorization findings
- CSRF + email-change endpoints: the classic account-takeover chain — change the victim's email with CSRF, then request a password reset
This is why the scan engine treats them as a family rather than isolated checks: Clickjacking Framability Proof (Browser PoC), the Deep CORS Scanner with its origin matrix, CSRF token and SameSite analysis, plus adjacent logic checks — Host Header Injection Reflection, CRLF Injection Proof, Web Cache Poisoning and Cache Deception, and Race Condition probes — because real attacks chain these primitives together, and so should a real assessment.
Fixes in One Place
- Clickjacking:
Content-Security-Policy: frame-ancestors 'self'(or'none') on every HTML response - CORS: explicit origin allowlist; never reflect arbitrary origins with credentials enabled
- CSRF: server-validated tokens on all state changes +
SameSite=Laxcookies + origin checks on sensitive routes - Cache layers: never cache authenticated responses; treat
Cache-Controlon personalized content as a security control
Scan Your Site for the Whole Family
The free 2MNY scan covers headers and cookie fundamentals; deep scans run the browser-level clickjacking proof and the full CORS origin matrix with evidence. See every scanner in the family on the features page, or self-host the open-source core from GitHub.
Related reading: Security Headers Explained · XSS: Types and Detection · API Security Testing Checklist
1 What is clickjacking and how do I prevent it?
Clickjacking embeds your site in a transparent iframe and tricks users into clicking elements they cannot see — a "Delete account" button that the user thinks is a video play control. Prevent it with X-Frame-Options: DENY (or SAMEORIGIN) and a Content-Security-Policy frame-ancestors directive; both are checked by every 2MNY scan.
2 How does a CORS misconfiguration put my site at risk?
CORS with a permissive policy — reflecting arbitrary Origins, allowing credentials with a wildcard, or whitelisting too broadly — lets any website read authenticated responses from your API in a visitor's browser. That turns a same-origin protection into a data-exfiltration channel for tokens, personal data, and internal endpoints.
3 What is the difference between CSRF and XSS?
CSRF makes the victim's browser perform an unwanted action on your site (transfer money, change email) using credentials the browser sends automatically; XSS injects attacker-controlled script into pages other users view, which can do anything the user can do — including defeating CSRF tokens. XSS is generally the more severe finding because it enables full session control.
4 Can scanners really detect logic bugs like these?
The deterministic signatures of the underlying mistakes are detectable: missing frame-ancestors headers, permissive CORS reflection, missing CSRF tokens on state-changing forms, cookie flags (SameSite) that leave requests unprotected. 2MNY tests each pattern with benign, self-verifying probes so findings come with evidence you can reproduce.
