Browser Trust Boundaries: CORS, CSRF and Redirects
Reflected origins with credentials, SameSite, modern CSRF against APIs, clickjacking, postMessage handlers and open redirects that carry real impact.
The browser enforces origin boundaries the application did not choose, and most findings here come from an application re-opening one of them on purpose.
CORS
Dangerous CORS rarely depends only on *. The real question is which origin is allowed to read a credentialed response. CORS is a browser policy controlling cross-origin response access. Access-Control-Allow-Origin and Access-Control-Allow-Credentials are part of the decision. Reflecting Origin without validation, trusting weak suffix checks or accepting null may expose authenticated responses to an attacker-controlled site. I test controlled origins, lookalike subdomains, null and credential behavior in a real browser. curl alone does not reproduce browser policy. A bad CORS policy becomes exfiltration only when the endpoint also returns sensitive data using credentials the browser sends on that request.
1
2
3
4
5
Origin: https://evil.example
# Look for:
Access-Control-Allow-Origin: https://evil.example
Access-Control-Allow-Credentials: true
Modern CSRF
SameSite reduced simple CSRF significantly, but real applications still create exceptions through methods, subdomains and login flows. CSRF uses credentials automatically sent by the browser to perform an action initiated by another site. Session cookies are the classic case. SameSite Lax allows some top-level navigations and behavior changes with method and cookie attributes. Same-site subdomains also matter. I confirm cookie attributes, anti-CSRF tokens, Origin or Referer validation and which content types the endpoint accepts. A JSON endpoint may remain vulnerable if it also accepts form encoding, text/plain or an alternate method reaching the same action.
1
2
3
4
POST /account/email HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=attacker%40example.test
SameSite Cookies
A single word in Set-Cookie changes which cross-site navigations carry the user session. SameSite Strict, Lax and None control cookie sending in cross-site contexts. None requires Secure in modern browsers. Site and origin are different concepts. Two subdomains may be cross-origin while remaining same-site. I inspect Set-Cookie, domain, path, Secure, HttpOnly and the real navigation flow before drawing a CSRF conclusion. Browsers apply modern defaults when SameSite is missing. Legacy WebViews or embedded clients may behave differently.
1
Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax
Clickjacking and UI Redressing
A safe button can trigger the wrong action when another site can place it invisibly under the user’s cursor. Clickjacking uses framing and visual composition to trick users into clicking UI from another origin. X-Frame-Options and CSP frame-ancestors control who may embed the page. Sensitive views need the policy consistently. I build a visual PoC with opacity and positioning, confirm whether one click is enough and check independent CSRF protections. JavaScript frame busting is fragile. Browser-enforced headers should provide the control.
1
2
Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: DENY
postMessage Security
postMessage intentionally crosses origins. Security depends on which senders the receiver accepts and what it does with the message afterward. window.postMessage enables communication between windows, iframes and tabs. The receiver receives event.origin and event.source to validate the sender. Handlers that accept *, use weak suffix checks or ignore origin may receive commands and data from untrusted sites. I enumerate listeners in JavaScript, map message schemas and test from a controlled origin before changing sensitive payloads. Even with a correct origin check, message data remains untrusted. If the handler sends it to innerHTML or eval, another vulnerability class appears.
1
2
3
window.addEventListener('message', e => {
if (e.origin.endsWith('example.com')) handle(e.data);
});
Open Redirects With Real Impact
An isolated open redirect often has limited impact. Inside a flow that trusts the domain, it may complete the missing step required to leak a credential. Redirectors receive a destination and return 3xx or equivalent navigation. Prefix allowlists and parser differences create bypasses. OAuth redirect URIs, SSO, magic links and security filters may trust the intermediate domain and follow the redirect outside. I prove the redirect to a controlled URL and then look for a trust relationship that treats the domain as an allowed destination. Reporting generic phishing as critical weakens the finding. High impact requires a reproducible technical chain.
1
2
GET /redirect?next=https://attacker.example HTTP/1.1
Host: trusted.example