Frontend Web Security Interview Questions: XSS, CSRF, CORS and More (2026)

Frontend web security interview questions test whether you can reason about browser boundaries. You should be able to explain where untrusted data enters, where it is rendered, which cookies are sent automatically, which origins can read responses, and which checks must happen on the server.

The best answers are scenario-based. A definition of XSS, CSRF, or CORS is only the first step. Interviewers want to know what you would inspect, what you would change, what tradeoff you would accept, and how you would verify that the fix works.

For technical accuracy, use official references as your source of truth: the OWASP Top 10 for broad application risk, the OWASP XSS Prevention Cheat Sheet, the OWASP CSRF Prevention Cheat Sheet, MDN Web Security, MDN CORS, MDN CSP, MDN Set-Cookie, and MDN postMessage. Interview-question lists are useful for prompts; official docs are better for the actual answer.

The browser-boundary mental model

Most frontend security answers become clearer if you first name the boundary. Do not start with "make it secure." Start with what the browser, frontend, API, or server is allowed to trust.

Core interview questions and model answers

1. What is XSS, and how do you prevent it in frontend code?

XSS happens when untrusted data is interpreted as executable code in a page. In frontend interviews, connect the answer to the exact rendering path: where the data came from, which DOM sink receives it, and which parsing context the browser uses.

A good answer:

• Render plain text as text, not HTML.
• Use framework escaping correctly.
• Avoid unsafe sinks such as innerHTML when the content should be text.
• Encode output for the right context: HTML text, attribute, URL, CSS, or JavaScript.
• Sanitize only when the product truly allows rich HTML.
• Use CSP as a second layer, not as the only XSS defense.

Common mistake: saying React, Vue, or Angular makes XSS impossible. Framework escaping helps with text rendering, but unsafe HTML APIs, unsafe URL handling, third-party scripts, and server-rendered templates can still create XSS risk.

2. How can XSS happen in a React app?

React escapes text by default, but React does not remove every XSS path. XSS can still happen through dangerouslySetInnerHTML, untrusted markdown or HTML renderers, direct DOM manipulation through refs, dangerous URL schemes passed to DOM APIs, third-party scripts, and HTML created outside React.

Interview-ready answer:

"I would first check whether the value is rendered as text or HTML. If it is plain text, React's escaping is usually the right path. If the product needs rich text, I would sanitize with an allowlist, validate link protocols, avoid dangerous DOM sinks, and add tests for stored payloads. I would also check CSP and any third-party scripts on that page."

3. What is the difference between validation, encoding, and sanitization?

Validation checks whether input has the expected shape. Encoding changes output so the browser treats it as data in the current context. Sanitization removes or rewrites unsafe parts of content that is intentionally allowed to contain markup.

Example:

• Validate that a profile URL starts with https:// or an allowed app route.
• Encode a display name before it appears in HTML.
• Sanitize rich-text comments so only allowed tags and attributes remain.

Common mistake: saying "sanitize all input" as a universal answer. For plain text, the safer answer is usually to render it as text. Sanitization is for cases where the product intentionally allows rich content.

4. What is a safe sink?

A safe sink treats data as text or a controlled value instead of executable markup. Examples include textContent, form value, and framework text interpolation when used normally.

The caveat matters: a sink is safe only for the right context. Hardcoded safe attribute names are different from dynamically choosing an attribute name. A URL attribute is different from normal text. An interviewer will often follow up with innerHTML, href, markdown, or rich-text examples to check whether the answer survives detail.

5. What is CSRF?

CSRF tricks a logged-in browser into sending a state-changing request that includes the user's cookies. The attacker may not be able to read the response, but the server may still receive and process the request.

Defenses include:

• Unpredictable CSRF tokens or a double-submit pattern, depending on the app architecture.
• SameSite cookies as defense-in-depth.
• Origin or Referer checks for sensitive state-changing requests.
• Fetch Metadata headers when the application can use them.
• No state-changing side effects on GET.

Common mistake: thinking HttpOnly prevents CSRF. HttpOnly prevents JavaScript from reading a cookie; it does not stop the browser from automatically sending that cookie.

6. What do HttpOnly, Secure, and SameSite protect?

Cookie attributes reduce different risks, so name the risk instead of calling a cookie "secure."

Also mention that cookie Path is not an access-control boundary. It controls when the browser sends a cookie; it should not be treated as protection from unauthorized reading.

7. What is CORS, and why is it not authorization?

CORS is a browser-enforced mechanism that controls whether frontend JavaScript from one origin may read a response from another origin. An origin is the scheme, host, and port.

Good answer:

• Same-origin policy restricts browser script access by default.
• CORS headers let the server tell the browser which origins may read a response.
• Some requests trigger a preflight OPTIONS request.
• Credentialed CORS needs deliberate cookie/auth handling and cannot use Access-Control-Allow-Origin: *.
• CORS does not authenticate the user or authorize the action.
• Non-browser clients can still send requests, so the API must enforce auth and authorization.

Common mistake: debugging React code when the actual problem is the API's CORS headers. If a request works in Postman but fails in the browser, check browser security rules before rewriting components.

8. Where should a frontend store tokens?

There is no universal answer. The right storage choice depends on the auth model, threat model, and product constraints.

An interview-ready answer names the tradeoff: cookies reduce JavaScript token theft but require CSRF thinking; browser storage can simplify bearer-token flows but makes XSS theft more damaging. Short lifetimes, rotation, least privilege, refresh strategy, and server-side revocation matter more than declaring one storage location always safe.

9. What does Content Security Policy do?

CSP lets a site restrict which resources a page can load and which scripts can execute. It can reduce XSS impact by blocking inline scripts, javascript: URLs, unexpected script sources, and dangerous APIs such as eval() when the policy is strict enough.

A good answer:

• Use CSP as defense-in-depth, not a replacement for safe rendering.
• Prefer nonces or hashes for scripts instead of broad allowlists.
• Avoid unsafe-inline unless there is a temporary migration reason.
• Roll out with Content-Security-Policy-Report-Only before enforcing a risky policy.
• Consider Trusted Types for reducing DOM XSS in apps with many dangerous sinks.

Common mistake: adding a loose policy with unsafe-inline and many wildcard sources, then treating the page as protected.

10. How can postMessage be used safely?

window.postMessage lets a window communicate with another window it references, such as a popup, parent, or iframe, even across origins. Workers and MessagePort objects have related messaging APIs, but targetOrigin and event.origin checks here apply specifically to window-to-window messaging.

Use a specific targetOrigin when sending. On receive, validate event.origin, check event.source when you expect one particular window, validate the message shape, and avoid sending secrets through generic message channels. If the message changes auth state, payment state, or account data, treat the receiver like any other trusted integration and document the expected source, origin, and schema.

Common mistake: using * for sensitive messages or trusting every message event because it arrived in the browser.

11. What security checks belong in the frontend?

Frontend checks are useful for UX and accidental misuse, but they are not authorization. The frontend can hide irrelevant actions, disable impossible actions, validate form shape, and show useful auth recovery states. The server must enforce permissions and input validation for every sensitive operation.

Good answer:

• Treat hidden buttons as convenience, not access control.
• Handle 401 as unauthenticated and 403 as authenticated but not allowed.
• Do not leak sensitive resource details in error messages.
• Test direct API calls, not only UI clicks.

12. How do iframes and clickjacking matter?

Clickjacking tricks a user into interacting with a page framed by another site. The modern answer is to control who can embed the page, usually with the CSP frame-ancestors directive. Older systems may still use X-Frame-Options.

When your app embeds other content, review iframe sandbox permissions, allowed origins, postMessage contracts, and whether sensitive pages can be framed at all.

Common mistake: talking only about CORS. CORS controls browser script access to responses; it does not decide whether another site can frame your page.

13. How do dependencies and third-party scripts create frontend risk?

Frontend code often runs with access to page content, user interactions, tokens in browser storage, and API responses. A third-party script, tag manager, or compromised dependency can therefore expand the damage from a single bug.

Good answer:

• Ask what data the script can see.
• Scope scripts to the pages that need them.
• Use CSP to limit allowed sources.
• Use Subresource Integrity for immutable third-party files when the integration supports CORS and a fixed file hash.
• Keep lockfiles, review major upgrades, and treat audit output as a signal rather than an automatic fix command.
• Avoid unnecessary client-side packages for small tasks.

14. Can frontend code contain secrets?

No real secret should be shipped to the browser. Anything in JavaScript bundles, source maps, HTML, network requests, local storage, or devtools-visible config should be treated as public.

Public API keys can be acceptable when the provider expects browser use and enforces restrictions server-side, such as allowed origins, scopes, quotas, and abuse controls. Private API keys, signing secrets, database credentials, and service-role tokens belong on the server.

For OAuth in SPAs, mention PKCE. PKCE improves public-client authorization flows, but it does not turn a browser into a place where client secrets can be hidden.

15. How do service workers affect security review?

Service workers can intercept requests, cache responses, and keep behavior active beyond the current page. Review their scope, update strategy, cached sensitive data, logout behavior, and whether an old worker can serve stale authenticated content.

A good answer separates caching bugs from authorization bugs. Clearing UI state on logout is not enough if a service worker can still return sensitive cached responses.

Scenario drills that interviewers actually value

Definitions help, but scenarios show judgment. Practice these as two-minute spoken answers.

Worked example: rich-text comments

"Users can write comments with links, bold text, and lists. How would you prevent XSS?"

Start by asking whether the product needs plain text, markdown, or HTML. If plain text is enough, render it as text and avoid HTML. If rich text is required, define an allowlist of tags and attributes, sanitize on a trusted processing path, validate URL protocols, and avoid dangerous DOM sinks in the client.

Then verify the final DOM, not only the stored string. Test stored payloads, reflected payloads, image error handlers, unsafe links, malformed HTML, and post-sanitization mutations. CSP should reduce impact if something slips through, but it is not the primary fix.

Interview-ready answer:

"React escaping handles plain text, but rich text changes the problem. I would keep the allowed formatting small, sanitize with an allowlist, validate links so javascript: cannot become an href, render through a controlled component, and test stored comments in the rendered DOM. I would also check which third-party scripts run on the page because they change the impact of an XSS bug."

Worked example: credentialed CORS API

"The frontend at https://app.example.com calls https://api.example.com/me with cookies. It works in Postman but fails in the browser."

Postman is not enforcing browser CORS rules. The server must return CORS headers that allow the exact frontend origin. If credentials are included, the frontend request must use the right credential mode, and the server cannot rely on a wildcard origin for a credentialed response.

The API still needs authentication and authorization. CORS decides whether browser JavaScript may read the response; it does not prove that the user is allowed to access /me.

Interview-ready answer:

"I would check the browser console and network panel first. If credentials are involved, I would verify the request credential mode, the exact Access-Control-Allow-Origin, Access-Control-Allow-Credentials, the preflight response, and the cookie attributes. After that, I would still check the API auth path because CORS is not authorization."

Worked example: hidden admin action

"The UI hides the Delete user button for non-admins. Is that enough?"

No. Hiding the button reduces accidental clicks and keeps the UI cleaner, but it does not enforce permission. A user can call the API directly, replay a request, use another client, or inspect the network request from an admin session.

The server should verify authorization for the delete action. The frontend should handle 403 deliberately, avoid leaking sensitive details, and keep the UI state consistent after a denied request.

Interview-ready answer:

"The frontend should hide the button for UX, but the API must enforce the permission. I would test by calling the endpoint directly as a non-admin and expecting 403. The UI should show a clear not-allowed state and not reveal extra data about the target user."

Answer depth by level

Common weak answers and better directions

30 frontend security questions to practice

How to practice for interviews

Practice by drawing the boundary first: browser, frontend code, API, cookie jar, third-party script, user-controlled input, storage, or server permission check.

1. Explain why a malicious site can send a form POST but cannot read a protected response without CORS.
2. Take one UI that renders user content and list every source, sink, and output context.
3. Review a login flow and identify where tokens live, when they expire, and how logout clears client state.
4. Design a forbidden-action UI and explain what the server must still enforce.
5. Practice REST API interview questions and add security follow-ups to each API answer.

For each answer, name the browser or server boundary and one verification step. For example, an XSS answer should end with a rendered-DOM test; an authorization answer should end with a direct API call using an unprivileged account.