277 JavaScript Frontend Developer Interview Questions & Answers

Reflected XSS puts attacker input into the current server response, stored XSS saves it and later renders it for visitors, and DOM-based XSS is created by client JavaScript. Prevent them by keeping untrusted values as text, encoding for the output context, sanitizing only intentional HTML, and avoiding unsafe DOM sinks.

This question asks how harmful content supplied by an attacker can reach another person's browser in three different ways. In one case, a search value is immediately sent back on the page. In another, a comment is saved and shown to later visitors. In the third, the page itself reads part of the address and inserts it into the page. For each path, explain who supplied the value, whose account is at risk, where the value becomes dangerous, what information or actions could be exposed, and where the application must stop the problem.

1. Should I assume the search query and saved comment are rendered by a trusted server, while the URL fragment is handled only by browser JavaScript?
2. Should the saved profile comment allow plain text only, or is some user-authored HTML intentionally supported?
3. Should I include defense-in-depth controls such as Content Security Policy and Trusted Types after explaining the primary prevention for each path?

Cross-site scripting, or XSS, happens when attacker-controlled data is treated as executable browser content instead of ordinary data. The attacker's code then runs in the vulnerable application's origin. That means it can interact with the page using the same browser origin as the legitimate application and may read JavaScript-accessible data or perform actions available to the current user.

Suppose the application receives a search request such as ?q=.... The attacker controls the q value. A trusted server reads that value and builds an HTML response containing it. If the server places the value into an HTML, attribute, script, URL, or another executable context without the correct context-specific encoding, the browser parser can interpret attacker-controlled data as markup or code.

The attacker-controlled input is the search query. The origin is the vulnerable application's origin. The victim is typically a user who opens an attacker-crafted URL, possibly while authenticated. The parsing sink is the location in the generated response where attacker-controlled data reaches an HTML or related browser parser. Protected assets include private page data, authenticated capabilities, and JavaScript-readable credentials or tokens. A session cookie marked HttpOnly cannot be directly read by injected JavaScript, but XSS can still make same-origin requests or perform actions using the victim's authenticated browser session.

Prevention must occur when the server generates the response. Treat the search query as data and apply contextual output encoding for the exact destination. For normal visible text, render it as text rather than executable HTML. Input validation can reject values that violate business rules, but filtering suspicious characters is not a complete XSS defense.

Suppose an attacker submits a profile comment. The attacker controls the comment. The trusted server saves it in persistent storage. Later, another visitor opens the profile and the stored value is rendered. If that value reaches an executable HTML context or unsafe client-side sink without safe handling, attacker-controlled content can execute in the visitor's browser.

The attacker-controlled input is the saved comment. The origin is the vulnerable application's origin. The victim is any later visitor whose browser renders the unsafe value. The sink may be a server-generated HTML position interpreted by the browser parser or a later client-side DOM operation that turns the stored value into HTML. Protected assets include each visitor's JavaScript-accessible data and authenticated capabilities.

If profile comments should be plain text, render them as text using contextual encoding, textContent, safe DOM APIs, or framework escaping. If the application intentionally supports limited rich HTML, sanitize that HTML with a well-maintained allowlist-based sanitizer before it reaches an HTML-capable sink. Sanitization is appropriate when HTML is intentionally allowed; it is not a universal replacement for context-specific output encoding.

Stored XSS describes persistence, not necessarily the final execution mechanism. For example, the server could safely return a stored comment in JSON, but client JavaScript could later introduce XSS by assigning that comment to innerHTML.

Suppose the page reads location.hash, which contains the URL fragment after #. The attacker controls the fragment. URL fragments are normally handled in the browser and are not included in the HTTP request sent to the server. Client JavaScript reads the fragment and passes it to an unsafe sink such as innerHTML. The browser then parses that string as HTML, which can create attacker-controlled executable content.

The attacker-controlled input is the URL fragment. The origin is the vulnerable page's origin. The victim is the user who opens the crafted URL. The source is the browser-side value read from location.hash. The sink is the client-side DOM or HTML-parsing API that interprets the value as markup. Protected assets include page data, JavaScript-readable tokens, and authenticated actions available from that origin.

Prevention must occur in the client-side data flow. If the fragment is supposed to be displayed as text, use textContent, createTextNode, safe DOM APIs, or framework rendering that escapes text by default. Do not pass untrusted strings to innerHTML, outerHTML, insertAdjacentHTML, or similar HTML-parsing sinks. If application functionality genuinely requires HTML, sanitize the content with an appropriate HTML sanitizer before using the required HTML sink.

The important distinction is where attacker-controlled data becomes executable browser content. With reflected XSS, the server commonly puts unsafe attacker-controlled data directly into the current response. With stored XSS, attacker-controlled data is first persisted and later becomes unsafe when a server or client rendering path interprets it as executable content. With DOM-based XSS, client JavaScript itself reads an untrusted source and sends it into an unsafe DOM sink, so the original server response can be completely safe.

This is why the best analysis follows data from source to sink. The storage location alone does not determine the final execution mechanism. A stored value can later cause DOM-based XSS if browser JavaScript handles it unsafely.

For plain text, keep untrusted values as text. On the server, use output encoding appropriate to the exact context. In browser JavaScript, prefer textContent, createTextNode, safe attribute APIs, and framework rendering that escapes values by default.

Avoid APIs that interpret untrusted strings as HTML. innerHTML, outerHTML, insertAdjacentHTML, and similar sinks should not receive untrusted content. Framework escape-bypass features require the same caution because they deliberately disable normal escaping.

When the product intentionally supports user-authored HTML, use a well-maintained sanitizer with a strict allowlist of permitted elements, attributes, and URL forms. Do not try to create a complete XSS defense by manually removing suspicious strings such as <script> because dangerous browser parsing behavior is broader than one tag or pattern.

Content Security Policy, or CSP, can reduce the impact of an XSS mistake by restricting which scripts may execute. A strong nonce- or hash-based CSP is valuable, but CSP does not replace safe source-to-sink handling.

Trusted Types can add another browser-side protection layer by restricting selected dangerous DOM sinks so that ordinary strings cannot be passed to them without going through approved policies. Trusted Types is defense in depth and still requires correct application logic and carefully designed policies.

Sensitive session cookies should normally use HttpOnly, Secure, and an appropriate SameSite setting. HttpOnly prevents injected JavaScript from directly reading the cookie value. It does not make XSS harmless because malicious same-origin code may still perform authenticated actions from the victim's page.

CSRF is a different security problem. CSRF tricks a browser into making an unwanted authenticated request, while XSS executes attacker-controlled content in the application's origin. XSS can frequently defeat normal CSRF assumptions because the injected script is already running within the trusted origin.

CORS and the same-origin policy are also not primary XSS defenses. The same-origin policy limits cross-origin access, but successful XSS runs with the vulnerable application's own origin privileges. CORS controls whether selected cross-origin responses can be read by requesting origins; it does not make unsafe same-origin rendering safe.

The frontend must never contain server secrets or long-lived privileged credentials. Browser storage such as localStorage is readable by JavaScript running in the same origin, so successful XSS can expose sensitive values stored there. Prefer designs that minimize sensitive credentials available to frontend JavaScript.

Third-party scripts and dependencies can also increase XSS and supply-chain risk because scripts running in the page can receive significant application privileges. Minimize unnecessary third-party code, review dependencies, keep them updated, and use controls such as CSP and Subresource Integrity where appropriate. These controls support the primary XSS defenses rather than replacing them.

Clickjacking is separate from XSS and is not central to these three attack paths. If relevant to the application's broader security design, prevent unwanted framing with CSP frame-ancestors or equivalent framing protections.

If untrusted content cannot be safely rendered, fail closed by displaying it as inert text or rejecting the unsupported rich-content operation rather than falling back to raw HTML. Security logging should record enough information to diagnose failed validation, sanitization, CSP violations, or unsafe rendering attempts, but it must not record session tokens, secrets, or unnecessary personal data.

Verify each control with automated and manual tests. Use harmless test strings containing HTML-significant characters and markup-like content, then confirm that they appear as inert data instead of being interpreted as executable content. Test the reflected search-query path, the stored-comment path for later visitors, and the client-side URL-fragment path separately. Review server templates for correct context-specific encoding, search frontend code for unsafe DOM sinks, test sanitizer configurations when HTML is intentionally allowed, and monitor CSP or Trusted Types reports during development and controlled rollout.

1. Identify each attacker-controlled source: the search query, stored profile comment, and URL fragment.
2. Identify the origin and victim context for each path.
3. Trace each value across server and browser trust boundaries to its final parsing or DOM sink.
4. Decide whether the destination requires plain text or intentionally supported HTML.
5. For plain text, use context-appropriate output encoding, textContent, safe DOM APIs, or framework escaping.
6. For intentionally supported HTML, sanitize with a strict allowlist before the HTML sink.
7. Remove unnecessary unsafe sinks such as innerHTML.
8. Add defense-in-depth controls such as CSP, Trusted Types, secure cookies, and dependency controls where relevant.
9. Define safe failure behavior so unsafe content becomes inert text or is rejected rather than rendered as raw HTML.
10. Verify every source-to-sink path with tests and log failures without secrets.

The normal runtime cost is small. Rendering a plain string safely takes work roughly proportional to the length of that string. HTML sanitization costs more because the sanitizer must parse and inspect the supplied markup, but user-generated comments are usually small enough for this to be practical. CSP and Trusted Types usually add little runtime cost, although their policies require configuration and testing. Memory usage for these defenses is normally proportional to the content being processed. The larger production cost is maintenance: developers must understand output contexts, avoid dangerous sinks, keep sanitizers and dependencies updated, and test new rendering paths.

Common mistakes include saying all three XSS types are solved by validating input; treating stored XSS as dangerous only when the value is saved rather than when it reaches an executable sink; assuming DOM-based XSS must involve a server response; using innerHTML for data that should be text; using one generic escaping rule for HTML text, attributes, JavaScript, CSS, and URLs even though output handling is context-specific; sanitizing ordinary text when safe text rendering is simpler; using framework escape-bypass APIs without reviewing the trust boundary; assuming CSP alone fixes XSS; believing HttpOnly cookies make XSS harmless; confusing XSS with CSRF, CORS, or the same-origin policy; keeping long-lived sensitive tokens in JavaScript-readable browser storage without considering XSS exposure; and logging payloads together with secrets or session data.

Explain every case using the same pattern: attacker-controlled source, origin and victim context, sink, protected data or capability, and prevention point. Emphasize that reflected XSS commonly becomes unsafe during current server-response generation, stored XSS persists before later unsafe rendering, and DOM-based XSS becomes unsafe in client JavaScript. Finish with safe text rendering first, sanitization only for intentional HTML, and CSP plus Trusted Types as defense in depth.

The same-origin policy is a browser security rule that limits one origin from reading or manipulating another origin's resources. An origin is the combination of scheme, host, and port. CORS can selectively allow cross-origin reads, but the trusted server must still enforce authentication and authorization.

The practical idea is simple: a page from one website should not normally be able to read private information from another website that you also use. Without this protection, a harmful page could try to inspect information from your email, bank, or another signed-in site. The browser creates a boundary based on where each page came from. Some actions across that boundary are still possible, such as showing an image, following a link, or sending a form. But directly reading protected information from another site is usually stopped unless that site gives permission.

1. Would you like examples of both allowed and blocked cross-origin interactions?
2. Should I also explain how CORS can permit selected cross-origin reads?

The same-origin policy, often called SOP, is a browser security rule that limits how a document or script from one origin can read or interact with resources from another origin.

An origin is defined by three parts:

1. Scheme, such as https.
2. Host, such as app.example.com.
3. Port, such as 443.

Two URLs are same-origin when these three values match, using the effective port for the scheme. For example, https://app.example.com/page and https://app.example.com/profile are same-origin. http://app.example.com, https://api.example.com, and https://app.example.com:8443 are different origins because the scheme, host, or port differs.

The main security purpose is to stop JavaScript running on one origin from automatically reading sensitive information that belongs to another origin. For example, a malicious site should not be able to open a user's banking site in another context and freely inspect its DOM or read authenticated API responses.

The policy does not block every cross-origin action. Browsers intentionally allow several kinds of cross-origin use. A page can commonly navigate to another site, submit an HTML form, load an image, load certain stylesheets, or embed some resources. However, JavaScript is generally prevented from reading a cross-origin document's DOM or reading a cross-origin network response unless an applicable browser mechanism permits it.

A useful distinction is sending versus reading. A browser may allow a cross-origin request to be sent even when JavaScript is not allowed to read the response. For this reason, a server cannot rely on the same-origin policy to protect state-changing operations. The trusted server must independently enforce authorization and use appropriate CSRF protections when browser credentials can be sent automatically.

CORS, or Cross-Origin Resource Sharing, is different from SOP. SOP is the browser's default isolation rule. CORS is a mechanism in which a server returns HTTP response headers that tell the browser which origins may access a response from JavaScript. Depending on the request, the browser may first send a preflight request to check whether the method and headers are permitted. CORS does not authenticate the caller, does not decide what an authenticated user is authorized to access, and does not stop non-browser clients from sending requests directly to the server.

CSP, or Content Security Policy, is also different. CSP lets a site restrict which sources may provide scripts, styles, images, frames, and other content. It is commonly used to reduce risks such as cross-site scripting. CSP does not define whether two URLs have the same origin and does not replace SOP or server authorization.

CSRF protection solves another problem. Cross-Site Request Forgery occurs when a malicious site causes a user's browser to send an unwanted request to another site using credentials that the browser may include automatically. SOP can often prevent the malicious page from reading the response, but that does not guarantee the request was not sent or processed. Protections can include suitable SameSite cookie settings, CSRF tokens, and server-side Origin or Referer validation when appropriate.

Authentication answers, 'Who is this user or client?' Authorization answers, 'What is this authenticated identity allowed to do?' SOP and CORS answer neither question. The trusted server must enforce authorization for every protected operation and resource.

The main tradeoff is isolation versus legitimate integration. Strong origin isolation protects users, but modern applications often place the frontend and API on different origins. CORS provides a controlled way to permit required browser access. A good production configuration allows only the origins, methods, headers, and credential behavior that the application actually needs instead of granting broad access by default.

Safe failure means that when cross-origin reading is not permitted, frontend code should handle the browser's failure without exposing protected response data or sensitive diagnostic information. Applications should avoid logging cookies, authorization headers, access tokens, session identifiers, or secrets. Frontend code must never contain server secrets or long-lived private credentials.

To verify the control, test the application in a real browser. Use browser developer tools to compare same-origin and cross-origin requests, inspect relevant request and response headers, and confirm that an unapproved origin cannot read protected responses. Also test authenticated endpoints directly on the server to confirm that authorization is enforced independently of browser-origin controls.

1. Compare the scheme, host, and effective port of the page and target resource.
2. If all three match, treat them as the same origin for SOP purposes.
3. If they differ, identify the interaction type, such as navigation, resource loading, form submission, DOM access, or JavaScript response reading.
4. Expect cross-origin DOM access and response reading to be restricted unless a specific browser mechanism permits them.
5. If legitimate cross-origin API access is required, configure narrow server-side CORS rules.
6. Independently enforce authentication, authorization, and relevant CSRF protections on the trusted server.
7. Verify the behavior in an actual browser and confirm that unauthorized origins cannot read protected data.

There is no useful Big-O time or memory complexity to calculate for the same-origin policy because it is a browser security rule, not an application algorithm. The browser performs origin checks as part of normal web security enforcement. The important costs are operational and maintenance costs. Teams must correctly manage frontend origins, API origins, CORS rules, credentials, cookies, development environments, and deployment changes. Rules that are too broad can expose data to unwanted origins, while rules that are too strict can break legitimate browser access. Automated and browser-level tests should cover expected production and development origins.

Common mistakes include saying that SOP blocks every cross-origin request. It often prevents JavaScript from reading data rather than preventing every request from being sent. Another mistake is defining an origin using only the domain and forgetting the scheme and port. Candidates also confuse CORS with authentication or authorization, assume CORS protects a server from direct non-browser clients, or claim SOP prevents CSRF. Another error is relying on browser restrictions instead of enforcing authorization on the trusted server. Finally, broad CORS rules should not be used without understanding exactly which origins need access and whether credentials are involved.

Start with one sentence: SOP prevents one origin from freely reading or manipulating another origin's data. Then define origin as scheme, host, and port. Give one allowed and one blocked example, explain the important difference between sending and reading a request, and finish by separating SOP from CORS, CSP, CSRF protection, authentication, and server-side authorization.

XSS is a vulnerability where untrusted data becomes executable content in another user's browser context. It may be reflected, stored, or DOM-based. Prevent it with safe DOM APIs, contextual output encoding, careful sanitization when HTML is intentionally allowed, plus CSP and Trusted Types as additional defenses.

Cross-site scripting happens when a website receives information from somewhere it should not fully trust and accidentally lets that information act like instructions. An attacker can prepare harmful content that runs when another person opens a page. The harmful content may then act as that person on the affected website. It could read information shown on the page, change what the person sees, or perform actions available to that person. The main goal is simple: outside information should stay ordinary information unless the site deliberately allows carefully cleaned rich content.

1. Do you want me to explain reflected, stored, and DOM-based XSS separately?
2. Should I also cover browser defenses such as Content Security Policy and Trusted Types?
3. Is intentionally allowed user HTML, such as rich-text content, part of the scenario?

Cross-site scripting, or XSS, is a vulnerability in which untrusted data is interpreted as executable browser content in another user's security context instead of remaining harmless data. The practical security decision is to preserve the boundary between data and code.

Reflected XSS occurs when attacker-controlled input is included in content that is returned or rendered for a request and is then interpreted as active browser content. A common example is unsafe use of a query-string value in generated page content. Stored XSS occurs when attacker-controlled content is saved, such as in a comment or profile field, and later delivered to users. DOM-based XSS describes XSS caused by unsafe client-side DOM processing: JavaScript reads attacker-controlled data and passes it to a sink that interprets it as active content. DOM-based XSS describes where the unsafe processing occurs and can overlap with reflected or stored delivery patterns.

A useful way to reason about XSS is with sources and sinks. A source is where potentially untrusted data enters frontend logic. Examples include location.search, location.hash, form values, postMessage data, browser storage, and API responses containing user-controlled values. A sink is an API or operation that can interpret a value as HTML, JavaScript, a URL, CSS, or another active browser context. A classic dangerous HTML sink is innerHTML when it receives untrusted content.

For ordinary text, prefer APIs that preserve the value as text. For example, use textContent, document.createElement, append, or other DOM operations that do not parse an untrusted string as HTML. Modern frameworks normally escape interpolated text by default, so keep that protection enabled and treat raw-HTML escape hatches as security-sensitive operations.

When output encoding is required, it must match the destination context. HTML text, HTML attributes, JavaScript strings, CSS, and URLs have different parsing rules, so one generic encoding function is not safe for every destination. In frontend code, avoiding string-built executable markup and using safe DOM or framework APIs is usually easier to reason about than manually encoding complex output.

If the product intentionally allows user-authored HTML, such as rich-text formatting, normal text encoding would remove the intended markup. In that case, use a well-maintained HTML sanitizer with a strict allowlist appropriate to the application's needs. The sanitizer should remove or neutralize dangerous elements, attributes, URL schemes, and other executable content. Do not treat regular-expression filtering, simple character removal, or input validation alone as complete XSS protection.

XSS can compromise information and actions available to the affected page. An injected script may read sensitive DOM content, read JavaScript-accessible browser storage, modify the interface, send data elsewhere where browser policy permits, or make requests using the victim's authenticated browser context. If an authentication cookie is HttpOnly, injected JavaScript cannot directly read that cookie, which reduces cookie theft. However, the script may still issue same-origin requests that automatically include the cookie, so HttpOnly reduces impact but does not solve XSS.

Authentication and authorization are separate concerns. Authentication establishes who the user is. Authorization determines what that user is permitted to do. XSS may cause requests to be made as the authenticated user, but the trusted server must still enforce authorization for every protected operation. Frontend checks are useful for user experience but are not a trusted authorization boundary.

Content Security Policy, or CSP, is defense in depth. A strong policy can restrict the scripts and other resources a page may execute or load and can reduce the impact of some injection mistakes. It does not replace correct output handling because policies can contain gaps and XSS defenses should not depend on CSP alone. Where practical, prefer nonce- or hash-based script policies and avoid broad allowances such as unsafe-inline.

Trusted Types is another defense for DOM XSS. When enforced, it can restrict assignments to supported dangerous DOM injection sinks so that arbitrary strings cannot be assigned directly. Values for those sinks must instead come through approved Trusted Types policies. This makes dangerous DOM operations easier to control and detect. Trusted Types complements safe DOM construction, contextual encoding, and sanitization; it does not replace them.

Other browser security controls address related but different threats. The same-origin policy limits interactions between different origins. CORS determines when frontend JavaScript may read certain cross-origin responses; it is not an XSS defense. CSRF protections address unwanted authenticated requests initiated from another site; they do not neutralize script already running inside the trusted origin. Frame-ancestors in CSP or X-Frame-Options can reduce clickjacking. These controls are useful, but none substitutes for preventing XSS.

Cookies that carry sessions should use appropriate security attributes such as HttpOnly, Secure, and a suitable SameSite policy. Avoid storing long-lived bearer tokens in JavaScript-readable storage when a safer architecture is available because XSS can read values exposed to page JavaScript. Browser storage is not a place for server secrets. Never put server secrets, private signing keys, database credentials, or other long-lived server credentials into frontend code because anything delivered to the browser must be treated as accessible to the user and to code running in that page.

Third-party scripts and dependencies also affect the XSS threat model. A third-party script loaded into the page generally runs with significant access to the page's JavaScript environment and DOM. Minimize unnecessary third-party scripts, review what is loaded, keep dependencies maintained, use lockfiles and appropriate dependency-review practices, and apply CSP or related controls where practical. Supply-chain compromise is not the same vulnerability as XSS, but malicious JavaScript running in the origin can create similar consequences for users.

File previews also need careful handling when user-controlled files can contain active content. Do not assume every uploaded file is passive. Render untrusted formats using an approach appropriate to the file type, content type, and isolation requirements rather than injecting file contents directly into the application's DOM as HTML.

Privacy matters during both prevention and investigation. Security logging can record useful events such as blocked policy violations, sanitizer rejections, or dangerous-sink detections, but logs should avoid session tokens, credentials, sensitive page contents, or unnecessary personal data. Safe failure means that if content cannot be safely rendered, the application should display it as harmless text, omit it, or reject it rather than falling back to an unsafe rendering path.

To verify the protection, trace untrusted data from each source to its eventual sink. Test suspicious paths with harmless payloads that reveal whether markup or script would be interpreted without causing damage. Review raw-HTML framework features, dangerous DOM sinks, sanitizer configuration, and contextual encoding. Where enabled, inspect CSP and Trusted Types violation reports. Automated security tests can help, but manual review of trust boundaries remains important because XSS depends heavily on how data moves through the application.

1. Identify trust boundaries and list sources of untrusted data, including URLs, forms, messages, browser storage, uploaded content, third-party data, and API responses containing user-controlled values.
2. Trace that data to sinks that can interpret HTML, JavaScript, URLs, CSS, or other active content.
3. Prefer textContent, createElement, safe DOM operations, or normal framework escaping instead of parsing untrusted strings as HTML.
4. When encoding is necessary, use output encoding specific to the exact destination context.
5. If the product intentionally permits HTML, sanitize it with a maintained allowlist-based sanitizer and keep the HTML-capable rendering path narrow.
6. Add CSP and, where practical, Trusted Types as defense in depth.
7. Reduce impact with secure cookie settings, careful token handling, server-side authorization, and minimal third-party script privileges.
8. Verify controls by reviewing dangerous sinks, testing trust boundaries with harmless security payloads, inspecting policy violations, and confirming that rejected content fails safely.

Safe DOM APIs and normal framework escaping usually add almost no meaningful performance cost. Contextual output encoding also has small CPU and memory cost because it transforms strings before output. HTML sanitization costs more because the sanitizer must parse and inspect the supplied markup, and its cost generally grows with the amount and complexity of content being sanitized. CSP and Trusted Types have little direct runtime cost compared with normal page work, but they add configuration, testing, rollout, and maintenance effort. The main operational cost is ongoing engineering discipline: tracking trust boundaries, reviewing dangerous sinks, testing changes, maintaining sanitizer rules, and controlling third-party code and dependencies.

Common mistakes include using innerHTML with untrusted strings; assuming input validation or character filtering alone prevents XSS; using one generic encoding method for HTML, attributes, URLs, JavaScript, and CSS; disabling framework escaping to render raw HTML without a justified and sanitized path; writing homemade sanitizers with regular expressions; assuming HttpOnly cookies make XSS harmless; relying on CSP as the primary fix; forgetting DOM-based sources such as location, postMessage, storage, or user-controlled API data; trusting data merely because it came from the application's own server; confusing CORS, CSRF protection, or the same-origin policy with XSS prevention; putting long-lived tokens or secrets in frontend-accessible locations; granting unnecessary trust to third-party scripts; failing to consider active content in file previews; logging secrets while investigating security events; and falling back to unsafe rendering when validation or sanitization fails.

Start with the trust boundary: untrusted data must remain data instead of becoming executable browser content. Then explain reflected, stored, and DOM-based XSS, identify sources and dangerous sinks, and give the defense order: safe DOM APIs or framework escaping first, contextual output encoding when required, sanitization only for intentionally allowed HTML, then CSP and Trusted Types as defense in depth. Mention that the trusted server still enforces authorization.

CSRF tricks a signed-in browser into sending an unwanted state-changing request with credentials the browser includes automatically, usually cookies. Defend with anti-CSRF tokens, SameSite cookies, Origin checks, safe HTTP methods, and re-authentication for sensitive actions. HTTPS, CORS, and POST alone are not sufficient.

Cross-site request forgery happens when a harmful website causes your browser to perform an action on another website where you are already signed in. Your browser may automatically include the information that proves you are signed in, so the second website may think the request came from you. The attacker usually cannot read the private response, but they may still cause an unwanted change, such as changing account settings. Protection means making sure an important request was intentionally started through a flow the trusted website allows.

1. Is the application using cookie-based sessions or another credential that the browser sends automatically?
2. Which state-changing operations are especially sensitive and should require re-authentication?
3. Does the application need any legitimate cross-site flows that affect SameSite or Origin-checking rules?

CSRF, or cross-site request forgery, is an attack where another site causes a user's browser to send an unwanted request to a trusted application. The important condition is that the browser automatically includes authentication credentials, most commonly session cookies.

For example, suppose a user is signed in to a banking site. If the bank accepts a state-changing request based only on the session cookie, a malicious page could cause the browser to submit a transfer request. The browser may attach the bank's session cookie automatically. Unless the bank performs additional checks, the server may see a valid authenticated session even though the user did not intentionally request the transfer.

Several conditions normally need to be true for a CSRF attack. First, the target endpoint must perform a meaningful state change. Second, the victim must have valid credentials that the browser will attach automatically. Third, the attacker must be able to construct a request the browser is allowed to send. Finally, the server must lack sufficient protection that proves the request came through an intended application flow.

Authentication and authorization are different. Authentication tells the server which user is signed in. Authorization decides whether that user is allowed to perform the requested action. The trusted server must always enforce authorization. CSRF protection adds another check: even if the user is authenticated and authorized, was this state-changing request submitted through a trusted flow?

A common defense is an anti-CSRF token. The trusted server creates an unpredictable token associated with the user's session or request context. The legitimate application sends that token with state-changing requests, for example in a hidden form field or a request header. The server verifies the token before making the change. A malicious cross-origin page generally cannot read the legitimate application's token because of the browser's same-origin policy. If the token is missing or invalid, the server must reject the request without changing state.

SameSite cookies provide an additional browser-level defense. SameSite=Strict prevents the cookie from being sent in most cross-site contexts. SameSite=Lax also blocks many cross-site uses, although cookies can still be sent in some top-level navigation cases, especially for safe methods such as GET. This is one reason GET and HEAD must never perform state-changing actions. SameSite=None allows cross-site cookie sending and requires Secure, so applications that need it must rely carefully on other CSRF controls as well. SameSite is strong defense in depth, but its setting must match legitimate application behavior.

The server can also validate the Origin header on state-changing requests. It should compare the header against an explicit allowlist of trusted origins, not perform a loose substring check. Referer may be used as a carefully considered fallback in some designs when Origin is unavailable. Applications must define safe behavior for missing headers because blindly accepting a missing Origin would weaken the control, while blindly rejecting it may break legitimate clients. Browser-based applications can usually use a strict policy for protected state-changing routes.

HTTP methods should follow their intended meaning. GET and HEAD should be safe and should not change server state. Creating, updating, or deleting data should use state-changing methods such as POST, PUT, PATCH, or DELETE. However, POST alone does not prevent CSRF. A malicious site can often submit a normal HTML form with a cross-site POST request, and the browser may still attach cookies automatically.

For especially sensitive operations, such as changing a password, changing a recovery method, adding a payment destination, or authorizing a financial transaction, the application can require recent re-authentication or another strong user-verification step. This limits the effect of both CSRF and a stolen authenticated session.

HTTPS is essential because it protects traffic against network interception and modification, but it does not prove that the user intended a request. A malicious HTTPS page can still cause a browser to send a request to another HTTPS site, so HTTPS alone does not stop CSRF.

CORS is also not a complete CSRF defense. CORS mainly controls whether JavaScript from another origin can read responses and whether certain non-simple cross-origin requests are allowed. Browsers can still send some cross-origin requests, including ordinary HTML form submissions, without the attacker receiving CORS permission to read the response. Therefore, blocking response access is not the same as preventing the state-changing request.

The same-origin policy has a similar limitation. It prevents many cross-origin reads, but it does not prevent every cross-origin request from being sent. CSRF specifically takes advantage of this difference between sending a request and reading its response.

CSRF risk is different when authentication uses a credential that an attacker-controlled page cannot make the browser attach automatically, such as a bearer token that the legitimate JavaScript application explicitly places in an Authorization header. That design can reduce classic CSRF exposure, although it introduces other concerns such as protecting the token from XSS and accidental exposure. The trusted server must still perform authentication and authorization correctly.

A secure design therefore combines controls based on the application's authentication model: keep state changes off safe methods, configure SameSite cookies appropriately, verify anti-CSRF tokens where required, validate trusted origins, enforce server-side authorization, and require re-authentication for especially sensitive actions. Failed validation must stop the operation before any state change occurs. Security logs may record useful request metadata and the reason for rejection, but they must not log session cookies, CSRF tokens, passwords, authorization credentials, or other secrets.

To verify the defenses, test protected state-changing endpoints from an unrelated origin. Confirm that requests with a missing or incorrect anti-CSRF token, an untrusted Origin, or another failed required check are rejected and cause no state change. Also test legitimate application flows, including any intentionally supported cross-site flows, so security controls do not break expected behavior.

1. Identify every endpoint that changes server-side state.
2. Determine whether authentication credentials, especially cookies, are attached automatically by the browser.
3. Ensure safe methods such as GET and HEAD are read-only.
4. Configure session cookies with an appropriate SameSite policy and use Secure and HttpOnly where appropriate.
5. Require and verify an unpredictable anti-CSRF token for protected state-changing requests when the authentication model needs it.
6. Validate Origin against an explicit trusted-origin allowlist and define safe handling for missing headers.
7. Enforce authentication and authorization independently on the trusted server.
8. Require recent re-authentication or stronger verification for especially sensitive actions.
9. Reject failed checks before changing state and log useful diagnostic information without secrets.
10. Test both legitimate application flows and simulated cross-site attacks to verify the controls.

CSRF defenses usually add very little processing cost. Token comparison and Origin checking take a small, nearly constant amount of work for each request. SameSite cookie enforcement is mainly handled by the browser. Server-managed token strategies may require a small amount of session data, while some token designs can avoid additional server storage. The main cost is maintenance: every relevant state-changing endpoint must use the correct controls, legitimate cross-site flows must be handled deliberately, and authentication or cookie changes must be security-tested.

Common mistakes include believing HTTPS prevents CSRF, treating CORS or the same-origin policy as complete CSRF defenses, assuming POST is automatically safe, allowing GET requests to change data, checking authentication without independently enforcing authorization, relying only on SameSite without considering legitimate cross-site requirements, using predictable or unverified CSRF tokens, accepting loosely matched Origin values, or accepting missing validation data without a defined security policy. Another serious mistake is performing part of the state change before CSRF validation finishes instead of failing safely first.

Start with the condition that makes CSRF possible: the browser may send authentication credentials automatically. Then explain anti-CSRF tokens, SameSite cookies, Origin validation, safe HTTP methods, and re-authentication. Clearly state that HTTPS, CORS, and POST alone are insufficient, and emphasize that the trusted server must enforce authorization and fail before changing state.

CORS is an HTTP-header mechanism that lets a server permit selected cross-origin browser reads that the same-origin policy would otherwise restrict. It controls allowed origins, methods, headers, and credentials. It is not authentication or authorization, and non-browser clients are not stopped by CORS.

CORS is a browser rule that controls when a website opened from one place can read information returned by a different website or service. Browsers normally keep different places separated so one website cannot freely read another website's replies. The service receiving the request can choose which websites are allowed to read its reply. Some requests can be sent immediately, while others need an extra permission check first. The service can also decide whether requests using cookies or similar account information are allowed. This browser rule does not prove who a user is or decide what that user may access.

1. Should I explain both simple requests and preflighted requests?
2. Should I include credentialed requests such as requests using cookies or HTTP authentication?
3. Should I also explain what security checks must still happen on the server?

CORS stands for Cross-Origin Resource Sharing. It is an HTTP-header mechanism through which a server tells a browser which cross-origin responses browser JavaScript is allowed to read.

An origin is the combination of scheme, host, and port. For example, https://app.example.com and https://api.example.com are different origins because their hosts differ. Browsers normally enforce the same-origin policy, which restricts JavaScript from reading responses from another origin. CORS gives the server a controlled way to relax that restriction for selected origins.

For a cross-origin request that qualifies as a CORS simple request, the browser can send the request without a preflight. It includes an Origin header, for example Origin: https://app.example.com. If the server wants that origin to be able to read the response, it can return Access-Control-Allow-Origin: https://app.example.com. The browser checks the CORS response headers before exposing the response to JavaScript.

A request qualifies as simple only when it satisfies specific CORS safelist rules. Its method must be GET, HEAD, or POST, and any manually set request headers and, for POST, the Content-Type must meet the CORS safelist requirements. For example, a POST using application/json is not a simple request and normally requires preflight.

When a request requires preflight, the browser first sends an OPTIONS request. That preflight asks whether the server permits the intended cross-origin operation. It contains Origin and Access-Control-Request-Method, and it can also contain Access-Control-Request-Headers when the real request plans to use non-safelisted headers.

The server can answer with headers including Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. The browser evaluates that response. If the preflight does not grant the required permission, the browser does not send the actual preflighted request.

Allowed origins should be configured deliberately. Access-Control-Allow-Origin: * allows any origin to access a CORS response when credentials mode is not include. For sensitive browser APIs, the server should normally allow only the origins that genuinely need access. If the server dynamically chooses an allowed origin from the request's Origin header, it must validate that value against a trusted allowlist. Blindly reflecting every supplied Origin defeats the purpose of restricting origins.

CORS can also govern methods and request headers. During preflight, Access-Control-Allow-Methods tells the browser which methods the server permits for the cross-origin request, and Access-Control-Allow-Headers tells it which requested non-safelisted headers are permitted. These are browser CORS permissions. They do not replace server-side authentication, authorization, input validation, or business rules.

Credentials need special care. For Fetch, credentials include cookies, TLS client certificates, and HTTP authentication credentials. A cross-origin Fetch request that needs credentials such as cookies commonly uses credentials: "include". For the browser to expose a credentialed cross-origin response, the server must return Access-Control-Allow-Credentials: true and must return a specific permitted origin in Access-Control-Allow-Origin; it cannot use * for that credentialed response.

CORS does not override cookie policy. Cookies are separately controlled by attributes such as Secure, HttpOnly, SameSite, Domain, and Path. Whether a cookie is actually sent therefore depends on cookie rules as well as the Fetch credentials mode. For cross-site cookie use, the cookie's SameSite policy is especially important.

Preflight permissions can be cached. A server may send Access-Control-Max-Age to tell the browser how long a successful preflight result may be reused, subject to browser-specific limits. This can reduce repeated OPTIONS requests and their extra latency. A long cache period can also delay the effect of a changed CORS policy until the cached permission expires.

When a server returns different Access-Control-Allow-Origin values depending on the request's Origin, it should send Vary: Origin. This tells HTTP caches that the response can vary according to the Origin request header and helps prevent cached CORS metadata for one origin from being incorrectly reused for another.

The most important security point is that CORS is not authentication. It does not prove who the user is. It is also not authorization. The trusted server must authenticate requests where required and enforce authorization for every protected resource and operation. A request coming from an allowed origin must not automatically be trusted.

CORS is also not a firewall. It does not generally prevent HTTP requests from reaching a server. CORS enforcement is mainly performed by browsers when scripts make cross-origin requests and try to access the results. Tools such as curl, backend services, native applications, and other non-browser clients do not become unable to call an API simply because its CORS policy would reject a browser origin. The server must therefore protect sensitive endpoints with real server-side security controls.

CORS should also not be confused with CSRF. CORS primarily governs cross-origin browser access to responses and introduces preflight checks for certain cross-origin requests. CSRF is an attack in which a victim's browser is induced to perform an unwanted authenticated action. Appropriate CSRF defenses can include SameSite cookies, anti-CSRF tokens, and server-side Origin or Referer validation where suitable. CORS alone is not a complete CSRF defense.

The practical rule is: allow only the browser origins that need cross-origin access, allow only necessary methods and headers, enable credentials only when needed, cache preflight results carefully, and keep authentication and authorization on the trusted server. Then verify the policy from both permitted and unpermitted origins.

1. Identify the frontend origin and API origin. If their scheme, host, or port differs, the browser request is cross-origin.
2. Decide exactly which browser origins need access and maintain a strict server-side allowlist.
3. Determine whether each request qualifies as a simple request or requires preflight because of its method, headers, or Content-Type.
4. Return only the required CORS response headers for approved origins, methods, and headers.
5. Enable credentialed cross-origin access only when necessary, use a specific allowed origin rather than *, and configure credentials consistently on the browser and server.
6. Keep authentication, authorization, validation, and CSRF protections independent of CORS.
7. Configure preflight caching carefully and send Vary: Origin when the response's allowed origin varies by request Origin.
8. Test permitted and unpermitted origins, simple requests, preflighted requests, credentialed requests, and authorization failures.

CORS itself usually adds little application CPU or memory work. A simple cross-origin request does not require an extra preflight network round trip. A preflighted request can add an OPTIONS request before the real request, increasing latency and server traffic. Successful preflight results can be cached to reduce that cost. The main operational cost is maintaining correct origin, method, header, credential, and cache policies across environments. CORS configuration also needs testing because a policy that is too strict can break legitimate browser clients, while a policy that is too broad can expose responses to unintended browser origins.

Common mistakes include saying CORS blocks all cross-origin network requests; confusing the same-origin policy with a rule that prevents all requests from being sent; treating Access-Control-Allow-Origin: * as appropriate for every API; blindly reflecting any Origin value; attempting to use wildcard Access-Control-Allow-Origin with credentialed requests whose credentials mode is include; forgetting that cookies have separate SameSite, Secure, HttpOnly, Domain, and Path rules; forgetting Vary: Origin when the allowed origin is selected dynamically; assuming a successful preflight authenticates or authorizes a user; treating CORS as a complete CSRF defense; and assuming CORS prevents curl, backend services, native applications, or other non-browser clients from contacting the API.

Start with the same-origin policy, then define CORS as the server-controlled HTTP-header mechanism that selectively permits cross-origin browser reads. Explain simple requests and preflight, then cover origins, methods, headers, credentials, and preflight caching. Finish by stating clearly that CORS is neither authentication nor authorization and that the trusted server must enforce access control.

textContent treats untrusted input as plain text, so HTML-looking characters are displayed instead of parsed into elements. innerHTML parses strings as HTML and can create XSS risk. Use a reviewed sanitizer only when the application intentionally allows rich HTML.

The safest choice depends on what the page is supposed to show. If a name or comment should appear only as ordinary text, the browser should display those characters exactly as data instead of treating them as page instructions. Data coming from your own application service can still contain unexpected or harmful values, so its source alone does not make it safe. If users are intentionally allowed to submit formatted content, the application needs a carefully reviewed cleaning step before showing that formatting. Different places on a page also need different safety rules.

1. Should the display name and comment be plain text only, or is any rich HTML intentionally allowed?
2. If rich text is allowed, which HTML elements, attributes, and URL schemes are permitted?
3. Does the application already use a reviewed HTML sanitizer or a Trusted Types policy?

I would start with the required output type. If the API values are only a display name and comment, I would assign them with textContent or create text nodes. textContent is a safe DOM construction choice for this case because the browser treats the value as text. For example, the string <img src=x onerror=alert(1)> appears as visible text instead of becoming an image element with an event handler.

innerHTML is different. It is an HTML-parsing DOM sink: assigning a string to it asks the browser's HTML parser to create DOM nodes from that string. If attacker-controlled or otherwise untrusted data reaches that sink, dangerous markup can become part of the document and may lead to cross-site scripting, or XSS. The important trust-boundary point is that data from an API under the application's own origin is not automatically safe. Stored user content, compromised backend data, or incorrectly validated data can still reach the frontend.

For plain text, I would therefore prefer textContent, document.createTextNode(), or framework rendering that escapes text by default. I would not use innerHTML merely because the data came from my own server.

If the product intentionally supports rich text, such as a limited set of links, emphasis, and lists, then textContent is not enough because it would display the markup literally. In that case, I would use a well-reviewed HTML sanitizer configured with a narrow allowlist and insert only the sanitizer's approved output. Sanitization is appropriate because some HTML is intentionally being preserved. Simple input filtering or a few regular expressions are not complete XSS defenses.

Safety is contextual. textContent solves the text-node case, but one encoding rule does not work everywhere. For normal non-event attributes, prefer specific DOM properties or carefully chosen DOM APIs and validate values according to what that attribute permits. Never place untrusted strings into inline event-handler attributes such as onclick. URL-bearing properties such as href and src need URL parsing plus allowed-scheme and, when required, allowed-destination checks because a URL can be dangerous even when it contains no HTML tags. Untrusted strings should not be turned into JavaScript code at all; avoid eval(), new Function(), inline script construction, and string-based event handlers.

Defense in depth can further reduce impact. A restrictive Content Security Policy can limit which scripts may execute if an XSS bug remains. Trusted Types, where supported and deployed, can restrict dangerous DOM injection sinks so arbitrary strings cannot casually reach them. If a site enforces Trusted Types for script-related sinks, rich HTML insertion must also follow the site's Trusted Types policy rather than assigning an ordinary string directly. CSP and Trusted Types support safe DOM construction; they do not make unsafe innerHTML assignments acceptable.

The safe failure behavior is simple: if rich content cannot be sanitized according to the approved policy, render it as plain text or reject that rich rendering instead of falling back to raw HTML. Security logging can record that sanitization or validation failed, but it should avoid storing secrets, authentication tokens, or unnecessary private content.

I would verify the control with tests containing HTML tags, event-handler attributes, malformed markup, suspicious URL schemes, and ordinary special characters. For plain-text fields, the test should confirm that attacker-controlled input produces only text and does not create attacker-controlled elements, event handlers, or executable code.

1. Decide whether the value is supposed to be plain text or intentionally allowed rich HTML.
2. Treat API-provided user-controlled strings as untrusted even when the API uses the application's origin.
3. For plain text, use textContent, text nodes, or framework text rendering instead of HTML-parsing sinks.
4. For intentional rich HTML, pass the value through a reviewed sanitizer with a narrow allowlist before any HTML insertion.
5. Handle normal attributes, URLs, event handlers, and script-related contexts with context-specific APIs and validation rather than reusing HTML encoding.
6. Never turn untrusted strings into JavaScript code.
7. Add defense-in-depth controls such as CSP and Trusted Types where appropriate.
8. Fail safely by rendering plain text or rejecting unsafe rich content.
9. Test with malicious markup, event handlers, suspicious URLs, malformed input, and normal special characters.

Common mistakes include saying that same-origin API data is automatically trusted, using innerHTML for plain text because it is convenient, escaping only < and > and calling the result safe, writing a home-grown regular-expression sanitizer, or claiming one HTML encoding method protects every context. Another mistake is using HTML escaping for URLs without validating schemes or required destinations. Using setAttribute() with attacker-controlled inline event-handler attributes is also unsafe. Candidates should not claim CSP or Trusted Types replaces safe DOM construction. For rich HTML, failing open to raw innerHTML when sanitization fails is unsafe. Tests should verify that dangerous input creates no executable DOM behavior.

Lead with the decision: plain text goes to textContent; intentional rich HTML requires reviewed sanitization before an HTML-parsing sink. Then explain why API origin does not equal trust, and finish by noting that attributes, URLs, event handlers, and script contexts need their own safe handling.