Security is often treated as a "back-end problem", but the browser is the front line and the front end carries real responsibilities. XSS, CSRF and CORS are the three topics that generate the most confusion — and demystifying them, knowing what is actually your responsibility, is what's expected of a senior.

XSS: code injected into your page

Cross-Site Scripting happens when an attacker manages to inject JavaScript that runs in other users' browsers — stealing cookies, sessions, or acting as the victim. There are three flavors:

• Stored: the malicious script is saved on the server (e.g., in a comment) and served to everyone.
• Reflected: the script comes in the URL/request and is reflected back in the response.
• DOM-based: the problem is purely in the client's JS, which dumps untrusted data into the DOM.

Defending against XSS

The golden rule: never trust input and always escape output according to context. Modern frameworks escape by default when rendering text — the danger lives in loopholes like innerHTML or dangerouslySetInnerHTML.

// DANGEROUS: interprets the user's HTML
el.innerHTML = comentarioDoUsuario;

// SAFE: treats it as plain text
el.textContent = comentarioDoUsuario;

As a second layer, CSP (Content Security Policy) is a header that tells the browser where scripts may come from, blocking injected code even if it slips through. Defense in depth.

CSRF: using your session without your knowledge

Cross-Site Request Forgery exploits the fact that the browser sends your cookies automatically. A malicious site makes your browser fire a request to a site where you're logged in — and the server, seeing the valid cookie, performs the action as if it were you (e.g., transferring money).

Defending against CSRF

• Anti-CSRF token: an unpredictable value that only your page knows and sends along; the attacker's site can't guess it.
• SameSite cookie: tells the browser not to send the cookie on requests coming from other sites.

Set-Cookie: sessao=abc; SameSite=Strict; Secure; HttpOnly

CORS: misunderstanding number one

Perhaps no topic causes more confusion. CORS is not a protection of your server that you "turn off". It's a policy of the browser: by default (same-origin policy), one site's JS cannot read responses from another origin. CORS is the mechanism by which a server authorizes specific origins to read its responses.

For "non-simple" requests, the browser first makes a preflight: an OPTIONS asking "may I?". If the server answers with the right headers, the real request proceeds.

The classic mistake: "disabling CORS to fix the error". You don't disable CORS — you configure the server to allow the right origins. Putting Access-Control-Allow-Origin: * on an API with credentials is opening the door, not fixing the lock.

It's important to understand: CORS protects the user (it stops one site from reading another's data on their behalf), it does not protect your API against direct access. Anyone calling your API from outside the browser (curl, another back end) ignores CORS completely — real authorization is authentication on the server.

What is the front end's responsibility

• Treat all input/output as suspect: escape before inserting into the DOM.
• Avoid innerHTML with user data; sanitize when unavoidable.
• Configure and respect CSP and SameSite/HttpOnly cookies.
• Understand CORS to diagnose (not "get around") origin errors.
• Never store secrets in the front end: everything that goes to the browser is public.

Interviews commonly ask you to tell XSS from CSRF or explain why CORS is not a server defense. Day to day, it shows up in the first "blocked by CORS policy" error or in a code review that catches a dangerous innerHTML.

Conclusion

XSS injects script (escape output and use CSP), CSRF abuses the session (token and SameSite) and CORS is a browser policy for authorizing cross-origin reads — not a security switch. Front-end security is, above all, distrusting all data and understanding who owns each responsibility.