Microsoft Frontend Developer (Junior Level) Interview Preparation Guide

Direct answer

In Python and Java, strings are immutable: every operation that looks like a modification, concatenation, replacing a character, actually allocates a new string object, leaving the original untouched. In C++, std::string is mutable by design: it supports true in-place modification of its own buffer. That single difference changes how you write efficient string-processing code: Python and Java favor building output through a mutable intermediate (a list of pieces, or Java's StringBuilder) and converting to a string once at the end, while C++ can often modify a std::string directly without ever needing that intermediate.

Structured elaboration

What mutable and immutable mean here

An immutable string type guarantees that once created, the sequence of characters it represents never changes. Any apparent edit, s = s + "x" in Python, s = s.concat("x") in Java, produces a brand new string object; the variable name is simply reassigned to point at it. A mutable string type, std::string in C++, or Java's StringBuilder/StringBuffer (which exist specifically because String itself is immutable), allows the underlying character buffer to be changed directly, without creating a new object each time.

How this affects algorithm design

For a problem like "reverse this string in place," C++ can genuinely reverse the existing std::string buffer with a two-pointer swap and zero extra allocation. The identical-looking task in Python or Java cannot touch the original string object at all, since it is immutable; the practical in-place technique is to convert to a mutable structure first, a list of characters in Python, a char[] or StringBuilder in Java, perform the two-pointer swap on THAT structure, and only build a new string from it at the very end. This is why coding-interview answers to "reverse a string in place" in Python conventionally operate on list(s): that satisfies the spirit of in-place swapping even though the original str object could never have been mutated directly.

Time complexity and memory usage

Because every "modification" of an immutable string allocates a new object sized to the result, repeated modification in a loop, appending a small piece to a string n times, costs O(n) time for a single append but can cost O(n^2) time in total across n iterations if done naively, since each append copies everything accumulated so far into the new object. A std::string or a StringBuilder/list-based accumulator instead grows its internal buffer with amortized doubling, giving O(n) total time cost for n appends, since only the buffer's OWN internal reallocation is doubling-based, not a full-string copy on every single append. The memory usage story mirrors the time complexity one: the immutable-string approach transiently holds BOTH the old and new copies at every step (peak memory proportional to the final size, plus churn from every discarded intermediate copy needing garbage collection), while the mutable-accumulator approach holds only the one growing buffer, at some points with a bit of unused reserved capacity from the last doubling.

Worked example

s = "hello"
before_id = id(s)
s = s + " world"
after_id = id(s)
print(before_id != after_id)   # True: concatenation created a new object

lst = [1, 2, 3]
lst_id_before = id(lst)
lst.append(4)
lst_id_after = id(lst)
print(lst_id_before == lst_id_after)   # True: append mutated the SAME object

Output:

True
True

The first check confirms that s + " world" really did allocate a new string object (the identity changes), demonstrating immutability directly rather than just asserting it. The second confirms the contrasting case: a Python list, which is mutable, keeps the same object identity across an in-place append. The equivalent contrast in C++ would show std::string::operator+= modifying the SAME underlying buffer (when capacity allows) rather than always allocating a new one, which is the concrete behavioral difference this question is asking about.

Trade-offs and pitfalls

A frequent mistake in interviews is claiming a Python or Java "in-place" string function actually mutates the original string object, when what really happened is the function returned a new string; the answer needs to be explicit about that distinction. Another is assuming C++'s mutability makes it strictly faster for all string work: C takes mutability further still, since a char*/array-backed string is always mutable at the byte level with no separate immutable type at all, but that control comes with none of the safety immutability provides elsewhere, buffer overruns and missing null terminators are a classic consequence. Go's string mirrors Python's model closely (immutable, with strings.Builder playing the accumulator role list+join plays in Python), and Kotlin's String is immutable for the same reason Java's is, since both compile to the same JVM string representation, so the same StringBuilder-based advice carries over unchanged. The practical lesson that generalizes across every one of these languages: whenever you need to build a string piece by piece in a loop, reach for the language's designated mutable-accumulator type rather than the plain immutable string type.

Goal & constraints
Bring color tokens to WCAG 2.1 AA while keeping brand look, minimizing dev friction, and preserving backward compatibility.

1) Clarify scope & metrics

• Audit tokens used in UI (text, UI chrome, icons, borders, states).
• Target contrast: 4.5:1 for normal text, 3:1 for large text / UI components.
• Measure current failures with automated tooling.

2) Tooling to identify failing tokens

• Token extraction: export design tokens (JSON) from Figma/design system repo.
• Automated checker: run axe-core + a11y contrast libraries (e.g., @axe-core/react, color-contrast-checker) against token pairs.
• Script example to compute contrast and list failing tokens:

// Node example using wcag-contrast
const { contrast } = require('wcag-contrast');
tokens.forEach(t => {
  const ratio = contrast(t.foreground, t.background);
  if (ratio < 4.5) console.log(t.name, ratio);
});

3) Approach to update tokens

• Prioritize: primary text, interactive controls, error/success states.
• Create accessible variants rather than replacing tokens: e.g., primary-500 -> primary-500 and primary-500-aa.
• Use color-math to nudge luminance (HSL lightness delta) to meet ratios while preserving hue. Provide designer-approved presets stored in tokens.
• Keep alias layer so components reference semantic tokens (e.g., text-primary) — swap aliases to new accessible values without changing component code.

4) Testing strategy

• Automated: CI step that fails PRs when new/changed token contrasts < thresholds.
• Visual regression: Percy/Chromatic snapshots for components before/after token toggle.
• Manual: QA checklist, keyboard/screen-reader smoke tests, and spot checks with color-blind simulators (Sim Daltonism).

5) Rollout phases

• Phase 0: Audit & token branch — generate report and proposed token deltas.
• Phase 1: Non-breaking patch — introduce accessible variants + CI checks; no consumer changes.
• Phase 2: Opt-in component theme — make components support an "aa" flag; internal apps test.
• Phase 3: Default switch — after 1–2 sprints of validation, flip aliases to accessible tokens; release notes & migration guide.
• Phase 4: Remediation follow-up — fix any visual regressions and update docs/design kit.

6) Trade-offs & communication

• Favor semantic token swaps to minimize dev changes. Some brand colors may need slight shifts; involve designers and stakeholders early. Provide fallback tokens for legacy integrations.

This plan balances brand fidelity (hue-preserving adjustments + design sign-off), developer effort (aliasing + CI automation), and backward compatibility (introduce variants and staged rollout).

Approach (brief)
Run up to limit tasks concurrently, start new ones as earlier promises settle, and collect results in original order. Use async/await with a queue of running promises and indexes to map results. Reject immediately if any task rejects.

// tasks: Array<() => Promise>, limit: number
async function promiseAllLimit(tasks, limit) {
  if (!Array.isArray(tasks)) throw new TypeError('tasks must be an array');
  const results = new Array(tasks.length);
  let nextIndex = 0;                // next task to start
  let active = 0;                   // currently running

  return new Promise((resolve, reject) => {
    function launch() {
      while (active < limit && nextIndex < tasks.length) {
        const i = nextIndex++;
        active++;
        // execute task
        Promise.resolve().then(() => tasks[i]())
          .then(value => {
            results[i] = value;
            active--;
            if (results.filter(r => r !== undefined).length === tasks.length) {
              resolve(results);
            } else {
              launch();
            }
          })
          .catch(err => reject(err)); // fail fast
      }
      // handle empty input
      if (tasks.length === 0) resolve([]);
    }
    launch();
  });
}

Scheduling & rejection handling

• Scheduling: start up to limit tasks; when one settles, decrement active and launch() next. Index mapping preserves order.
• Rejection: the implementation rejects immediately on the first task rejection (fail-fast). If you want to collect all results/errors, catch and store errors instead of calling reject.

Complexity

• Time: O(n) plus runtime of tasks; concurrency improves wall-clock runtime.
• Space: O(n) for results and bookkeeping.

Notes for frontend

• Useful for rate-limiting API calls (e.g., bulk fetches) to avoid overloading browser or server. Consider exponential backoff / retries for transient failures.

Direct answer
Matching the rigor of your evidence to the cost of being wrong, not maximizing data collection, is
the whole answer here. Ask three things fast: what decision does this signal need to support, what
is the cheapest proxy that is directionally correct even if imprecise, and what is the smallest
instrumentation change that gets that proxy today rather than next sprint.

Under time pressure with no instrumentation
If something needs an answer within a day or two and there's no logging in place, don't try to
build proper instrumentation first. Use whatever adjacent signal already exists for some other
purpose, server access logs, billing or usage records, an error-tracking tool set up for a
different reason, or even a manual sample, pulling fifty real examples and hand-reviewing them, to
get a directionally correct answer fast, and be explicit when reporting it that it's a rough
estimate, not a final number.

Under a budget constraint specifically
A budget constraint is a different pressure from a time constraint: you may have weeks, but can't
buy a new analytics tool or warehouse table. The answer leans on infrastructure already paid for,
application logs already emitted for debugging, an existing spreadsheet-based manual log an
operations team keeps, a support-ticket export, accepting slower turnaround rather than new spend.

When the spec itself defines no metrics
Before writing any code, define the minimum set of events that let you say "this sprint's work
shipped something real." For a new flow with no stated success metric, that minimum might be just
three events: flow started, flow completed, flow abandoned at a given step. That's enough to answer
"did this work" even before it can answer "why," and it's a far smaller lift than a full analytics
suite.

When the feature already shipped with nothing tracked
You can't go back in time, so the interim decision has to rest on proxies collected for other
purposes, server logs, database row-creation timestamps as a usage proxy, support-ticket volume
mentioning the feature, while proper forward-looking instrumentation gets added starting now. Be
explicit to stakeholders that the interim number is a backward-inferred proxy, not tracked data, so
they calibrate their confidence correctly, and state the date after which the number becomes
trustworthy on real data.

Applied to a scenario combining all four pressures
A team ships an in-app referral feature with no success metrics defined. Three weeks post-launch,
leadership asks in a Monday meeting whether it's working, wanting an answer for a board update two
days later, and there's no budget approved this quarter for a new analytics tool. With no
instrumented conversion funnel, the team pulls two things that already exist for free: a raw
database count of referral-code redemptions, and a manual sample of thirty support tickets
mentioning "referral" to gauge friction qualitatively. The answer delivered two days later: "119
referral codes were redeemed in the first three weeks, a real count from the database, against zero
specific complaints about the referral flow in a thirty-ticket sample, a rough qualitative signal,
not a precise satisfaction score; we don't yet have a true conversion rate because the flow's start
and abandon steps were never instrumented." That's honest, defensible, and useful, paired with a
one-sprint plan to add the three minimum events going forward, prioritized above lower-traffic
features specifically because referrals are likely to be asked about again at every future board
update.

Prioritizing instrumentation going forward
Once the immediate call is made, decide what to build permanently using the same risk-times-
frequency logic used elsewhere: instrument first whatever will be asked about repeatedly, a core
funnel step, a metric feeding a recurring business review, or whatever carries the highest cost if
you're caught blind again, and write that as a short ranked backlog rather than an open-ended "add
more logging" task.

Beyond data science
An SRE facing an outage on a legacy service with no tracing does the identical thing, using
adjacent signals like host-level CPU and network graphs or load-balancer logs to make a defensible
call in the moment, then adding proper tracing prioritized by which service will be asked about
again.

Direct answer
Open by telling the audience what you're going to cover and why it matters to them, signpost explicitly as you move between sections so they always know where they are, and close by restating the key takeaway rather than just stopping.

Structured elaboration

• Opening: state the topic, why the audience should care (what decision or understanding this affects them), and a brief roadmap of the two or three things you'll cover, in that order. This gives the audience a mental outline to hang the rest of the talk on.
• Signposting as you move through it: explicit verbal markers like "that's the background, now let's get into the actual recommendation" or "second point: ..." help a listener track structure that they can't see the way they could see slide headers or section breaks in a document.
• Body: cover the roadmap items in the order you promised; if you need to deviate, say so explicitly ("I said I'd cover three things, but I want to spend more time on the second one because it's the crux") rather than silently reordering.
• Closing: restate the single most important takeaway in one sentence, ideally the same conclusion you'd have led with in a BLUF-style (bottom-line-up-front) written summary. A talk that just trails off after the last data point leaves the audience to guess what they were supposed to walk away with.
• Time-boxing: decide roughly how much time each section deserves before you start, so the most important section doesn't get squeezed by running long on an earlier one.

Worked example
Opening: "Today I want to cover why our checkout conversion dropped last month, what we found, and what we're proposing to fix it. I'll spend most of the time on the fix, since that's the decision we need from this meeting."

Signposting mid-talk: "That covers the three causes we found. Now, the part that actually needs a decision from you: two options for the fix."

Closing: "So the recommendation is option two: it costs more upfront but avoids the recurring risk we saw with option one. That's the decision I'd like from this meeting."

Each of these three lines exists purely to orient the listener to structure, not to add new content.

Trade-offs and pitfalls

• A talk with too many signposts can feel mechanical; use them at genuine transition points, not after every sentence.
• Promising a roadmap and then not following it (skipping a promised section, or spending disproportionate time on something you said would be brief) breaks the audience's trust in your structure and makes them stop tracking it.
• For a very short talk (under two minutes), an explicit roadmap can eat too much of the available time; at that length, the opening and closing can collapse into a single BLUF-style sentence instead of a separate roadmap plus takeaway.

Direct answer. A long analytics dashboard with multiple widget panels needs a landmark structure that lets a screen reader user jump directly to the section they want, rather than tabbing or reading through the entire page linearly: a <main> landmark for the dashboard content, <section> elements with aria-labelledby pointing at each panel's visible heading, and a consistent heading hierarchy that reflects the panel structure.

Structure.

<main aria-label="Sales dashboard">
  <h1>Sales Dashboard</h1>
  <section aria-labelledby="revenue-heading">
    <h2 id="revenue-heading">Revenue</h2>
    ...
  </section>
  <section aria-labelledby="retention-heading">
    <h2 id="retention-heading">Retention</h2>
    ...
  </section>
</main>

Each <section> becomes a navigable landmark region (announced with its accessible name from aria-labelledby) in a screen reader's landmark-navigation list, letting a user jump straight to "Retention" without passing through every widget above it.

Heading hierarchy. One <h1> for the whole dashboard, <h2> for each panel, and <h3> for any sub-groupings within a panel (e.g. a panel with two related charts), never skipping a level (going from <h2> straight to <h4>), since screen reader users commonly navigate by heading level and a skipped level breaks the implied structure they're relying on.

Representing this in Figma. Figma has no native concept of landmark roles or heading levels, so the structure has to be represented explicitly, not left implicit in visual grouping: name each frame/layer to mirror the intended element and level directly (e.g. "H1 - Sales Dashboard," "Section: Revenue (H2)"), and mark each landmark's boundary with a dedicated annotation layer or an accessibility-annotation plugin (Stark, or Figma's built-in dev-mode annotations) so a developer can see the intended aria-labelledby target and landmark boundary without inferring it from a card's drop shadow or spacing alone.

Developer handoff. The handoff spec should be an explicit table, not just the visual design file: for every landmark, list its element/role, the accessible-name source (the heading id it's labelled by), and its heading level, so engineers aren't left inferring structure from font size and spacing. Call out the never-skip-a-level rule explicitly in the handoff notes, since heading level is a purely visual choice in Figma (font size and weight) that an engineer building from the file alone could easily misread as any level.

Trade-offs and pitfalls. A common real mistake on data-dense dashboards is treating every widget as its own <section> with no landmark label at all, which technically creates navigable regions but leaves them all announced generically as "region" with no distinguishing name, giving a screen reader user a long list of identical-sounding stops with no way to tell them apart without entering each one; the aria-labelledby connection to a real visible heading is what makes the landmark list actually useful rather than just technically present.

Direct answer

Count every character's frequency in one pass (a hash map or Counter), then make a second pass over the string returning the first character whose count is exactly 1. This is $O(n)$ time and $O(k)$ space, where k is the number of distinct characters. If the string arrives one character at a time and you must be able to answer "what's the first non-repeating character so far" at any point, keep a queue of once-seen candidates in arrival order and evict its front whenever that character's count rises above 1.

Structured elaboration

Two-pass approach, for a string you already have in full:

from collections import Counter

def first_non_repeated(s):
    """
    Return first non-repeated character in s, or None if none exists.
    Two-pass approach: O(n) time, O(k) space (k = distinct characters).
    """
    if not s:
        return None
    counts = Counter(s)
    for ch in s:
        if counts[ch] == 1:
            return ch
    return None

Streaming variant. The two-pass approach needs the whole string up front. If characters arrive one at a time and a query can land at any point, you cannot afford to rescan everything seen so far on every query. Instead, maintain a frequency map alongside a queue (double-ended queue) of characters that are currently unique, in the order they first appeared:

from collections import deque

class StreamingFirstNonRepeated:
    """
    Streaming variant: feed one character at a time via .push(ch) and query
    .current() at any point without rescanning history. O(1) amortized time
    per pushed character (each character enters and leaves the deque at most
    once), O(k) space for k distinct characters seen so far.
    """
    def __init__(self):
        self.counts = {}
        self.q = deque()

    def push(self, ch):
        self.counts[ch] = self.counts.get(ch, 0) + 1
        if self.counts[ch] == 1:
            self.q.append(ch)
        while self.q and self.counts[self.q[0]] > 1:
            self.q.popleft()

    def current(self):
        return self.q[0] if self.q else None

The queue's front is always the earliest-arrived character that is still unique, because any character that becomes non-unique gets evicted from the front the moment its count rises above 1 (it may sit behind the front briefly until it becomes the front, but it is removed by the time it would otherwise be reported).

Worked example

s = "swiss"
print(first_non_repeated(s))

tracker = StreamingFirstNonRepeated()
running = []
for ch in s:
    running.append(ch)
    tracker.push(ch)
    print(''.join(running), '->', tracker.current())

Output:

w
s -> s
sw -> s
swi -> s
swis -> w
swiss -> w

The full-string answer is w, matching the streaming tracker's final answer. Along the way you can see the answer change: after "s", "sw", "swi" the answer is still s (unique so far); once the second s arrives ("swis") the tracker evicts s from the front and reports w; the final s in "swiss" doesn't change the answer since w is still unique.

Trade-offs & pitfalls

Key points

• The two-pass approach is the simplest correct solution when the full string is available; don't reach for the streaming version if you don't need "answer at any point in time" semantics, since it adds a queue and eviction logic for no benefit.
• The streaming approach never needs to rescan from the start, but it does need to keep counts for every distinct character seen so far, and the queue can (temporarily) hold characters that later get evicted, so peak memory is still O(k) not O(1).
• Multi-codepoint or combined Unicode characters (for example, accented characters built from a base character plus a combining mark) are treated as separate codepoints by both approaches; if the requirement is "first non-repeating user-visible character" rather than "first non-repeating codepoint," you would need a grapheme-aware library instead of iterating raw codepoints.

Complexity

• Two-pass: time $O(n)$, space $O(k)$.
• Streaming: $O(1)$ amortized time per pushed character (each character is added to and removed from the queue at most once), space $O(k)$ for the counts and queue combined.

Edge cases

• Empty string: both approaches return None.
• All characters repeated: both return None (the two-pass loop finds no count-1 character; the streaming queue empties out).
• Single character: trivially non-repeating, both return it.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Direct answer

In the moment, say plainly that you don't yet know, without guessing out loud to fill the silence, immediately pair that admission with a concrete next step so it doesn't sound like a dead end, and afterward protect trust by actually following through on that plan and closing the loop even if the answer takes longer than hoped.

Structured elaboration

• Handling the moment. Resist the pressure to speculate confidently just to have something to say; a wrong guess stated as fact is worse than an honest "I don't know yet," because it can send the stakeholder's own decisions in the wrong direction. Say it plainly: "I don't have a confident answer for why that happened yet."
• Proposing an investigation plan on the spot. Immediately follow the admission with a specific next step and, if possible, a rough timeframe: "I'm going to check X and Y first, and I'll have an update by [a specific time]," rather than an open-ended "I'll look into it." This converts "I don't know" from a dead end into a plan the stakeholder can trust is moving.
• Maintaining trust during follow-up. Actually deliver on the timeframe given, even if the update is "still investigating, here's what I've ruled out so far," rather than the final answer. A stakeholder tolerates not having the answer yet far better than they tolerate silence after being promised an update. If the investigation takes longer, or turns up something uncomfortable, including a mistake, say that plainly too rather than softening it.

Worked example

A stakeholder asks why a report's numbers jumped overnight, and there's no confirmed reason yet. Instead of guessing, "probably a data refresh issue," the response is: "I don't have a confirmed reason yet, I don't want to guess and send you down the wrong path. I'm going to check the two most likely sources, the upstream data feed and a recent code change, and I'll update you by end of day either way." The follow-up happens by end of day as promised, even though the investigation isn't finished: "I've ruled out the code change, still checking the data feed, will have a final answer by tomorrow morning." The next day brings confirmation that it was an upstream data quality issue, along with what's being done about it. Trust holds because every promise about timing was kept, including the intermediate ones.

Trade-offs and pitfalls

Guessing confidently to avoid looking uninformed risks being wrong, which costs more trust than the original "I don't know" would have. Saying "I don't know" with no plan attached reads as unhelpful rather than honest. Promising a timeframe and then going silent when it's not met damages trust more than the original uncertainty did. And over-apologizing or being defensive in the moment can make the stakeholder more anxious rather than reassured that it's being handled.

Answer (frontend developer perspective)

Short summary
To have the browser include cookies when app.example.com calls api.example.com you must: 1) set the cookie on the API host with SameSite=None and Secure, 2) send fetch with credentials, and 3) configure CORS response headers to allow credentials and the exact origin (no wildcard).

Required cookie attributes (set by api.example.com)

• SameSite=None — allows cross-site requests.
• Secure — required when SameSite=None; cookie sent only over HTTPS.
• Domain=api.example.com (or Domain=.example.com if you want subdomain sharing) — cookie is only sent to matching host.
• HttpOnly — recommended for session cookies (prevents JS access, still sent with requests).
• Path and Expires/Max-Age as appropriate.

Fetch usage (frontend)

// include credentials so cookies are sent
fetch('https://api.example.com/data', {
  method: 'GET',
  credentials: 'include', // crucial: 'omit' or default will not send cross-site cookies
  headers: { 'Content-Type': 'application/json' }
});

CORS response headers (must be returned by api.example.com)

• Access-Control-Allow-Origin: https://app.example.com
  • Must be the exact origin; cannot be "*".
• Access-Control-Allow-Credentials: true
  • Allows browser to expose response when credentials are included.
• Access-Control-Allow-Methods: GET, POST, OPTIONS, ...
• Access-Control-Allow-Headers: Authorization, Content-Type, ...
• For preflight (OPTIONS) return 200 with the above headers.

Example response headers:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

Security implications & notes

• SameSite=None + Secure increases risk if the API is vulnerable to CSRF; protect endpoints with CSRF tokens or require custom authentication headers (e.g., bearer tokens).
• HttpOnly prevents XSS from reading cookies but not CSRF from sending them—use anti-CSRF measures.
• Do not use Access-Control-Allow-Origin: * when credentials are allowed — it will be ignored by browsers and is insecure.
• If you can, prefer storing tokens in memory or using Authorization headers (Bearer) to avoid cookie-based CSRF concerns; if you must use cookies, combine HttpOnly cookies with a double-submit CSRF token or SameSite=Lax for same-site flows where possible.