Senior Fullstack Developer Interview Preparation Guide - FAANG Standards

Direct answer

Range-based sharding groups keys into contiguous ranges (good for range queries, prone to hotspots on the newest range); hash-based sharding spreads keys evenly by hashing them (avoids that hotspot but destroys ordering, so range queries scatter across every shard); directory-based sharding uses a lookup service to map each key to a shard explicitly (most flexible for steering around hotspots, at the cost of operating and scaling that lookup service). For write-heavy user data, the right starting point is almost always hash-based, layered with directory-style overrides for the specific keys that turn out to be hot in practice.

Structured elaboration

At the simplest level, the choice comes down to one question: does your access pattern need range queries, or does it need even load distribution? Those two goals are usually in tension, which is why the three strategies exist.

Alternate shard-key dimensions. User ID is not the only reasonable key for user data. Two common alternatives, each changing the hotspot and locality picture:

• Partitioning by tenant (for a multi-tenant product): every row for one customer organization lives together, which keeps that customer's queries and transactions shard-local, but a single very large tenant can become a hot shard on its own regardless of hashing, and tenant sizes are rarely uniform.
• Partitioning by geographic region: keeps a region's data physically close to the users generating it and can satisfy data-residency requirements, but regions do not generate even load (one region's business hours are another's overnight lull), so this dimension needs the same hotspot vigilance as range-based sharding by time.

Either alternative needs a request-routing design that resolves a given request to the correct partition before any query executes: for tenant or region keys this is usually a straightforward lookup (tenant ID and region are typically known before the query is issued), but it is still an explicit routing decision, not something a plain hash of an opaque ID gives you for free.

A simpler way to hold the whole comparison in your head: shard-key choice is really a load-distribution and data-locality decision. If you need data that is accessed together to live together (range scans, tenant-local transactions, region-local latency), you are choosing locality over even distribution, and range- or directory-based sharding fits. If you need writes spread as evenly as possible and do not need that locality, hash-based sharding fits.

Worked example

A write-heavy user-activity table (one row per user action, high insert rate) is first sharded by signup-date range, since that was the easiest key to reach for. Under load, the shard holding "this week's" range becomes visibly hotter than the others, since all new activity lands there, exactly the hotspot risk in the table above. Switching the shard key to hash(user_id) spreads new writes evenly across all shards, because a hash has no notion of "this week." The cost: a query like "all activity in the last 7 days across all users" now has to fan out to every shard and merge results, whereas it used to touch one or two. If that query is rare and the write hotspot was the actual production problem, the hash-based trade is the right one; if that range query is core to the product, a directory-based approach (route the most recent, hottest range's writes across several shards explicitly, while keeping most historical data range-organized) is worth the added operational complexity instead.

Trade-offs & pitfalls

• Consistent hashing (not plain modulo hashing) is what makes hash-based sharding practical to rebalance; naive hash(key) % N reshuffles nearly everything when N changes, which erases the rebalancing advantage hashing is chosen for.
• Directory-based sharding trades data-movement cost for a new single point of scaling and consistency risk: the directory service itself must be highly available and kept correct, or every lookup through it is wrong.
• Secondary indexes are the detail teams most often discover too late: a design that looks fine for primary-key access can require an expensive scatter-gather or a whole extra index service the moment a "find by email" or "find by status" query shows up.
• Choosing tenant or region as the shard key without checking size distribution first is a common wrong turn: one outsized tenant or one high-traffic region can silently become the new single hot shard, defeating the purpose of sharding at all.

Direct answer

Give the reply-to-parent relationship a strong, causal ordering guarantee (a reply is never visible before the post it replies to), while letting everything else in the feed (impression counts, non-causal fan-out, feed ranking) settle down eventually. Achieve the causal guarantee without a full linearizable write path by attaching a compact causal timestamp to each write and holding a reply back at the read side until its parent is locally visible. Confirm it worked by measuring the ordering-violation rate directly (aim for effectively zero) and the write-to-visibility staleness distribution, not by trusting the design on paper.

Structured elaboration

Framing the guarantee

This is a per-feature consistency decision, not a system-wide one: only the parent-to-reply edge needs an ordering guarantee, so only that edge should pay for it. Making the whole feed strongly consistent to protect one relationship is the wrong instinct.

Mechanism: causal delivery, not full consistency

• Tag every write with a hybrid logical clock (HLC) timestamp, a logical clock that mixes physical time with a counter so causally related events can be ordered without comparing a full history per item.
• A reply carries a dependency: (parent_id, parent_HLC).
• At the delivery point in each region, hold a reply in a small buffer until its parent is present locally, showing a short "loading" state if needed, then release it. This gets you causal consistency (a specific point between strict linearizability, where every operation appears to happen instantly in one single global order that every reader sees the same way, and plain eventual consistency, which gives no ordering guarantee at all and just "settles" eventually) for exactly the edge that needs it.
• A full vector clock (one counter per replica) would also give causal ordering, but at a metadata cost that grows with the number of regions; HLC stays a fixed few bytes regardless of region count, which is why it is the better default at this scale (see the worked example).

The absorbed risk: this is not the same anomaly as a shopping-cart race

The reply-ordering problem is a single-writer, append-only causality problem: one thing must come after another. It should not be confused with the concurrent-write anomalies a feature like a shopping cart's quantity field runs into: lost updates (two concurrent writes to the same field, one silently overwrites the other) and write skew (two transactions each read a consistent snapshot, both commit valid-looking changes that are jointly invalid). Those need a different tool, optimistic concurrency control (a version check on write) or serializable transactions, because the problem is conflicting writes to the same value, not the order two different items become visible. Naming both anomaly families shows you are choosing the guarantee to fit the failure mode, not applying one mechanism everywhere.

Decision criteria to reuse elsewhere in the feed

Ask, for each field or edge: does a violation change what a user believes happened (a causality break) or does it just show slightly stale aggregate state (a like count)? Is the anomaly a mis-ordering (needs causal or session guarantees) or a lost or conflicting write (needs concurrency control)? What is the cost of buffering or retrying versus the cost of a global synchronous commit?

Worked example

Assume a mid-size product doing 5,000,000 replies per day globally, replicated across 6 regions.

Metadata overhead, HLC versus a full version vector (worst case, one entry per region that has touched the thread):

That gap is why HLC is the better default once you are geo-replicating at this volume: the version vector's cost scales with region count, HLC's does not.

Now size the read-side buffer. Assume cross-region replication lag has a 99th-percentile (P99) of 300 ms (illustrative; in practice you would pull this from your own replication metrics, not assume it):

Fifty thousand read-repair fallbacks a day is cheap; that number is what tells you a 300 ms buffer is a reasonable default rather than a guess.

Trade-offs & pitfalls

• Buffer timeout is the main dial: too short and you push load onto cross-region read-repair; too long and users occasionally see a stale placeholder instead of the reply.
• Hot threads (a viral post with a reply storm) can blow past the default buffer's assumptions; the fix is to synchronously fast-path-replicate just the parent for hot threads, not to raise the global timeout for everyone.
• Pitfall: conflating "causal ordering for one edge" with "the whole feed is strongly consistent." Interviewers listen for whether you can name the narrow guarantee you actually need.
• Pitfall: monitoring only the design's intent ("we use causal delivery") instead of the outcome (measured violation rate, measured staleness). A design without those two numbers wired up is unverified.
• Garbage-collect dependency-tracking state once a reply has been durably applied everywhere you care about; unbounded metadata retention is a quiet cost leak.

Direct answer

Start private, and address the impact of the behavior rather than the person's character. Only introduce a visible, group-level norm if the private conversation doesn't hold, and only escalate further if the pattern continues after that.

The move: graduated response, impact before intent

1. Private conversation first, soon after a recent instance. Waiting until frustration has built up makes the conversation land as an accumulated grievance rather than specific, addressable feedback.
2. Describe the observed behavior and its concrete effect, not a character judgment. "In the last two design reviews, an idea got dropped because it was talked over before it was finished" is addressable; "you're dominating meetings" is not.
3. Ask an open question rather than assuming intent. They may not be aware, or something specific (time pressure, a cultural norm from a prior team) may be driving it.
4. Agree on a visible cue or norm together, rather than telling them what to do. A shared agreement they helped design is one they'll actually hold themselves to.
5. If it continues, make the norm visible to the whole group without naming the individual (a "parking lot", a visible running list where off-track or repeated points get noted and revisited later instead of argued in the moment; or a rotating facilitator), and only return to a private, documented conversation, with specific instances, before considering escalation beyond the two of you.

Worked example

A senior engineer repeatedly interrupts and dismisses ideas in planning meetings, and quieter teammates have stopped proposing alternatives. You raise it privately, citing two specific instances and what was lost each time, and ask if something's driving the pattern. They didn't realize the effect and agree to a shared cue: a raised hand or a "hold that thought, back to you after" from whoever's facilitating. The behavior improves within a couple of meetings once the norm is visible and mutual rather than a private correction only they know about.

The same graduated shape applies to a very different kind of friction: two peers who've been informally swapping on-call shifts in a way the rest of the team has started to perceive as unfair. There the first conversation isn't about correcting a behavior, it's about surfacing that the arrangement looks uneven from outside and asking the two of them how they'd want it made visible. It still ends the same way structurally, not with a cue this time, but with a durable, documented agreement: who's allowed to swap, how it gets logged, and how the rest of the team is notified, so the fairness question doesn't quietly resurface every few weeks.

Trade-offs and pitfalls

Correcting someone publicly on the first instance humiliates them in front of peers and tends to produce defensiveness rather than change, even when the feedback is accurate. A private conversation that stays vague ("try to be more mindful in meetings") doesn't give them anything concrete to change and often needs repeating. When the underlying friction is actually about status or unclear role boundaries rather than a communication habit, a meeting norm won't fix it; that needs a structural conversation about who owns what, not a cue card.

Definition & goal
Critical CSS = the minimal subset of CSS required to render above-the-fold (initial viewport) content. Inlining it means embedding that CSS directly into the HTML <head> so the browser can paint the first view without fetching external stylesheets.

Why it improves perceived load time

• Removes render-blocking round-trip for the first paint, so content appears faster.
• Improves Largest Contentful Paint (LCP) and First Meaningful Paint (FMP), improving perceived performance for users.

Trade-offs

• Pros: faster first render, fewer requests, better SEO/metrics.
• Cons: larger HTML (caching less effective), duplication across pages, maintenance overhead, risk of missing edge cases causing flash of unstyled/incorrect layout.
• Mitigations: limit inline size (e.g., <14 KB), use page-level templates, server-side caching.

Simple extraction & serving process

1. Audit pages to identify common layouts and viewports.
2. Use a tool (Puppeteer, Critical, Penthouse) to render the page and extract above-the-fold CSS.
3. Minify and inline only the extracted rules into <style> in the head.
4. Load full CSS asynchronously (rel="preload" or load via JS, then swap rel to stylesheet).
5. Monitor metrics (LCP, CLS) and test across breakpoints; iterate and automate extraction during build.

I’d implement this in the build pipeline so critical CSS stays accurate and small while full CSS remains cached.

Direct answer
There are three common axes for deciding how to decompose a system into services: by business domain (Domain-Driven Design's bounded contexts), by technical surface area (splitting along data-store or infrastructure boundaries), or by team boundaries (whoever owns a piece of functionality gets a service). Business-domain decomposition is the default that ages best, because it tracks how the business actually changes over time; the other two axes are useful corrective signals, not primary decomposition strategies on their own.

Structured elaboration
Each axis optimizes for something different, and each has a failure mode when used alone. Business-domain decomposition (what does billing mean, what does user management mean, what does content delivery mean, each becoming its own service with its own data) tends to produce services whose boundaries stay stable even as the implementation underneath changes, because business concepts change more slowly than code. Technical-surface decomposition (split wherever the data store or infrastructure naturally differs, for example an analytics pipeline that needs a column store versus an online-transaction-processing (OLTP) path that needs a row store) is a good secondary signal, since forcing two workloads with very different infrastructure needs into one service creates real operational friction, but decomposing purely along technical lines without regard to the business concept tends to produce services that don't map to anything a product manager or a new engineer can reason about. Team-boundary decomposition (whoever owns it gets a service) optimizes for deployment autonomy and follows Conway's Law directly, but used alone it tends to fragment a single business concept across several services just because the org chart happened to split that way, creating coordination overhead between services that should have been one.

Worked example
Applying this to a product with billing, user management, and content-delivery features: billing and user management are natural, stable business-domain boundaries, each becoming its own service with a clear owner. Content delivery is more of a technical-surface concern (the actual bottleneck is serving large media efficiently, which pulls in content-delivery-network (CDN) and caching infrastructure decisions that don't map neatly to a single business domain); treating it as its own service is justified less by "it's a distinct business capability" and more by "it has a genuinely different infrastructure and scaling profile from the rest." If the org later splits user management across two teams (one for authentication, one for profile data) without a real business reason for the split, that's the team-boundary axis fragmenting a domain that should stay together, and it's worth pushing back on.

Trade-offs and pitfalls
The most common decomposition mistake is applying the technical-surface or team-boundary axis as the primary driver instead of a secondary check, producing services with unclear ownership from a product perspective, or services whose boundary exists only because two teams happen to sit in different parts of the org chart. Coupling shows up differently depending on the axis: business-domain decomposition risks under-splitting a domain that's actually grown too large for one team; technical-surface decomposition risks over-splitting a coherent business concept across several infrastructure-driven services; team-boundary decomposition risks mirroring org chart churn directly into architecture churn. The practical fix in all three cases is the same: use business domain as the default lens, and only cross it with the other two axes when there's a concrete, measurable reason (a genuinely different infrastructure need, or a genuinely different release cadence for a sub-piece of the domain).

Approach (brief)

Lift the text state to the nearest common parent so both siblings receive it as props. Keep only the minimal state in parent and compute derived data (word count) where needed to avoid extra renders.

Component hierarchy change

• App (holds state)
  • A (TextInput) — receives value + onChange
  • B (WordCount) — receives value or memoized wordCount

Where to place state

Place const [text, setText] = useState('') in App. Pass value={text} and onChange={setText} to A.

Code (concise)

// App.jsx
function App() {
  const [text, setText] = useState('');
  const handleChange = useCallback(v => setText(v), []);
  return <>
    <A value={text} onChange={handleChange} />
    <B text={text} />
  </>
}

// A.jsx
function A({ value, onChange }) {
  return <input value={value} onChange={e => onChange(e.target.value)} />;
}

// B.jsx
const B = React.memo(function B({ text }) {
  const wordCount = useMemo(() => text.trim() ? text.trim().split(/\s+/).length : 0, [text]);
  return <div>{wordCount} words</div>;
});

Avoiding unnecessary re-renders

• Memoize B with React.memo so it only rerenders when text changes.
• Use useMemo inside B to compute derived data (wordCount) — cheap and scoped.
• Use useCallback for handlers passed to children to keep stable references.
• If A updates cursor/selection independently, consider local controlled state in A and sync to parent debounce to reduce parent updates.

This keeps single source of truth, simple prop flow, and limits renders to when derived data actually changes.

Designing what a CI pipeline should capture on test failure is itself a debugging-under-pressure decision made ahead of time, so the right artifacts are already there when you need them later.

What to capture

Logs (structured, with the correlation/test ID), native core dumps and heap dumps for any crash (not just the test framework's own summary), a storage/retention policy that keeps failure artifacts long enough to investigate but not indefinitely (cost), and access controls appropriate to what's captured (a core dump can contain sensitive data). An automated triage step tags the suspected culprit commit (via a bisect-style comparison against recent history, meaning it checks which of the recent commits touched files the failing test actually covers, narrowing from many candidate commits down to the one most likely responsible,) and computes a running flakiness score per test so a genuinely new regression is distinguishable from a known-flaky test at a glance. Concretely, the flakiness score can be as simple as the fraction of the last N runs (say, the trailing 20) that failed for that specific test: a test failing 1 of its last 20 runs reads as known-flaky, while a test that passed its last 50 runs straight and then fails on this commit reads as a genuinely new regression, worth escalating immediately rather than auto-retrying.

Sizing detail versus cost (a related trade-off)

The same design question scales up to production tracing: high-cardinality, per-user or per-order tracing gives excellent debuggability for rare failures but costs meaningfully more in storage and can raise privacy concerns in a multi-tenant product. A pragmatic strategy: default to a lower, cost-controlled sampling rate for full detail, but retain the ability for on-demand detailed capture (temporarily raise sampling or enable full per-request tracing for a specific tenant/time window under investigation), plus tail-sampling (always keep detailed traces for requests that were slow or errored, regardless of the general sampling rate) so the rare, interesting cases are captured even when the average-case sampling rate is low.

Trade-offs and pitfalls

Capturing everything for every failure is the easiest policy to reason about but the most expensive to sustain; the tail-sampling plus on-demand-escalation pattern captures the cases that actually matter for debugging at a fraction of the always-on-full-detail cost, and is the standard resolution to this trade-off in both the CI-artifact and production-tracing versions of the same question.

Direct answer. Confirm it by checking the WHERE clause literally for a function call or type cast wrapped around the indexed column; the fix is to rewrite the predicate so the indexed column appears bare on one side of the comparison, moving any transformation to the constant instead.

Structured elaboration. An index on a column can only be used efficiently by predicates the engine can translate directly into a range or equality scan of that index's stored values. The moment the column itself is wrapped in a function (a date-extraction function, a case-normalization function like lower()) or compared to a value of a different type that forces an implicit conversion, the engine generally can no longer map the predicate onto the index's stored order and has to fall back to evaluating the function for every row, which usually means a full scan. The confirmation step is mechanical: look at the WHERE clause and ask "is the indexed column, unmodified, on one side of a comparison operator?" If not, that's very likely the cause, and EXPLAIN will typically confirm it by showing a scan rather than the expected index usage.

The fix comes in two shapes. Query-side: rewrite the predicate so the column is bare and any transformation moves to the constant side of the comparison, for example turning an equality-on-a-truncated-date into a range comparison against the bare timestamp column. Schema-side, when a query-side rewrite genuinely isn't possible (the transformation is fundamental to the business logic, like case-insensitive matching), create an expression index that stores the transformed value directly, so the index itself already reflects lower(email) and the query can match against it.

Worked example. I verified the query-side rewrite is correctness-preserving with a small dataset: a query filtering CAST(order_ts AS DATE) = DATE '2025-01-01' (non-sargable, wraps the column) against four rows returns order_ids 1 and 3; rewriting to the equivalent range form returns the identical set.

-- non-sargable: function wraps the indexed column, defeats the index
SELECT order_id FROM orders
WHERE CAST(order_ts AS DATE) = DATE '2025-01-01';

-- sargable rewrite: bare column, range comparison against two constants
SELECT order_id FROM orders
WHERE order_ts >= TIMESTAMP '2025-01-01'
  AND order_ts <  TIMESTAMP '2025-01-02';

Both return order_id 1 and 3 for a table with rows at 2025-01-01 10:00, 2025-01-02 09:00, 2025-01-01 23:59:59, and 2025-02-01 00:00, confirming the rewrite changes only the execution strategy, not the result.

Trade-offs and pitfalls. The rewrite has to be exactly semantically equivalent, not just "close": an off-by-one on the upper bound (using <= against the start of the next day instead of < the next day) would silently include an extra midnight row. When an expression index is the only realistic fix, remember every query that wants to benefit from it must use the exact same expression the index was built on; a query written slightly differently (a different function, or the same function with different argument order) won't match.

Complexity

The rewrite doesn't change the query's asymptotic complexity by itself, it changes whether an O(log n) index lookup or an O(n) scan is even available as an option.

Edge cases

Time-zone-aware timestamp columns need extra care: a naive date-range rewrite can shift results by the UTC (Coordinated Universal Time) offset if the column and the literals aren't in the same time zone convention. Boundary values exactly at midnight need the range's inclusive/exclusive ends checked carefully against the original semantics.

Direct answer

Triage fast to find the smallest change that removes the actual user-facing harm, use the shrinking window as a reason to scope down rather than attempt a full root-cause rebuild days before release, and tell stakeholders the real state and the fallback option early rather than quietly hoping the fix lands cleanly.

Structured elaboration

Diagnose fast and scoped: for a performance regression, use a profiler (an in-engine frame-time profiler for a game, or browser devtools for a web frontend) to find the specific function or asset actually causing the slowdown rather than guessing. For a UI deviating from the approved design, do a direct side-by-side comparison against the design file to produce a specific list of deviations rather than a vague sense that "it looks off."

Quick mitigations: for a performance issue, a targeted fix (reducing a specific effect's cost, lazy-loading an asset, capping a repeated computation) beats a broad refactor under this kind of time pressure. For a design deviation, fix whatever is visually significant or brand-critical first, and explicitly defer pixel-level polish that does not affect usability to a fast-follow.

Tools: a profiler to find the real hotspot, a visual diff or side-by-side screenshot comparison against the design spec, and a feature flag or config toggle that can instantly revert the change if the fix itself turns out risky right before release.

Communicate with stakeholders: give them the specific finding, not just "there's an issue," the fix plan, and a fallback (ship with the change flagged off, or revert to the last known-good build) if the fix is not verified in time, so the release date does not depend entirely on one fix landing perfectly.

Worked example

Four days from a mobile game's release, frame-rate profiling shows a specific particle effect added the previous sprint is causing a drop from 60 to 40 frames per second in one busy scene. Day one: profile and confirm it is that one effect, not a broader issue. Day two: reduce the effect's particle count and cap it behind a quality setting rather than removing it entirely, and verify frame rate recovers to around 58 to 60 in the same scene. Day three: regression-test the fix across the other scenes using the same effect. Day four, release day: ship with the capped effect, communicated to the team as a deliberate scope trim rather than a mystery late fix.

Trade-offs and pitfalls

The clearest pitfall is attempting a deep architectural fix for either kind of problem this close to release instead of the smallest safe change available. A second is not telling stakeholders until the last possible moment, which removes their ability to choose a fallback if the fix risks slipping. The same discipline applies to the design-deviation version of this problem: fix what actually matters to users and the brand, and explicitly log, rather than silently drop, the cosmetic deviations for a fast-follow patch instead of trying to close every gap before the date.

Direct answer

Cross-Site Request Forgery (CSRF) exploits the fact that browsers automatically attach a user's stored credentials, most commonly session cookies, to every request sent to a site, regardless of which page actually initiated that request; an attacker who gets a logged-in victim to load a crafted page can trigger a state-changing request to the real site, and the browser helpfully attaches the victim's valid session cookie along with it. At least four independent mitigations exist: CSRF tokens (the synchronizer-token pattern), the SameSite cookie attribute, verifying the Origin or Referer header on state-changing requests, and requiring a custom request header that a simple cross-site form cannot set. The attack only works at all because the browser auto-attaches cookies; when authentication instead lives in an Authorization header that the application code must explicitly set, a cross-site page has no built-in mechanism to attach it, which removes most of the classic CSRF threat model outright, at the cost of shifting the risk toward how that token is stored and whether it can be stolen via other means (most notably Cross-Site Scripting).

Structured elaboration

How CSRF works, mechanically. A user logs into bank.example.com and receives a session cookie. Without logging out, they visit attacker.example, which contains a hidden HTML form (or an auto-submitting fetch/image tag for GET-based variants) that targets bank.example.com/transfer with attacker-chosen parameters. When the victim's browser loads that page, it submits the form to bank.example.com, and because cookies are attached per-domain regardless of which page triggered the request, the victim's real session cookie rides along. If the server's only check is "is this session cookie valid," the request succeeds as if the victim had submitted it themselves, transferring funds, changing an email address, or performing whatever the endpoint does, with the attacker never touching the victim's credentials directly.

Typical attack chains. The classic chain is: victim is authenticated to a target site in one browser tab -> victim is lured (phishing link, malicious ad, compromised third-party page) to visit an attacker-controlled page in another tab or the same session -> that page auto-submits a form or fires a cross-site request to a sensitive endpoint on the target site -> the browser attaches the victim's cookie automatically -> the server performs the action believing it was a legitimate request from the authenticated user. A GET-based variant is even simpler and needs no form at all: an <img src="https://bank.example.com/transfer?to=attacker&amount=500"> tag fires a GET request the instant the page loads, which is exactly why state-changing operations should never be reachable via GET.

Mitigation 1: CSRF tokens (synchronizer-token pattern). The server generates a random, session-bound token, embeds it in the legitimate page's forms (as a hidden field) or exposes it for the client to attach as a header, and rejects any state-changing request that does not include a matching token. An attacker's cross-site page cannot read this token (it is not set as a readable cookie the attacker's origin can access, and same-origin policy blocks reading the real page's content from a different origin), so it cannot forge a request that includes the correct value.

Mitigation 2: SameSite cookie attribute. Setting the session cookie to SameSite=Lax or SameSite=Strict tells the browser itself not to attach the cookie on qualifying cross-site requests (all non-GET, non-top-level requests for Lax; effectively all cross-site requests for Strict), which blocks the classic hidden-form attack at the browser level before it ever reaches the server. This is a strong, low-effort layer, but should not be relied on exclusively, since it depends on the browser enforcing it correctly and does not cover every legitimate cross-site flow a real app might need.

Mitigation 3: Verifying Origin/Referer on state-changing requests. Modern browsers reliably send an Origin header on cross-origin requests (and often same-origin ones too for non-GET requests); a server can reject any state-changing request whose Origin does not match its own, which catches forged cross-site requests even from a client that ignores SameSite. Referer-based checking is an older, less reliable fallback (it can be stripped by privacy settings or proxies), so Origin is the preferred signal where available.

Mitigation 4: Requiring a custom header. A plain HTML form submitted cross-site can only set a limited set of headers and content types; requiring, say, an X-Requested-With header or a custom X-CSRF-Token header on state-changing requests means a bare cross-site form POST cannot satisfy the requirement at all, since forms have no mechanism to add arbitrary headers. This is a genuine partial defense on its own and a natural pairing with mitigation 1, since the CSRF token is commonly delivered exactly this way.

Cookie-based vs Authorization-header-based auth. CSRF as a threat model exists specifically because the browser attaches cookies automatically and without the page's cooperation. When authentication instead uses a bearer token sent in an Authorization header, the browser has no built-in mechanism to attach that header to a request initiated by a different origin's page; JavaScript on the attacker's page cannot set an Authorization header on a simple cross-site form submission at all, and a cross-site fetch call that tried to add one would need the token value in the first place, which the attacker's origin does not have access to under the same-origin policy. So switching authentication from cookies to an explicitly-attached Authorization header removes the classic CSRF attack surface almost entirely; the trade-off is that the application code must now securely obtain and store that token itself (commonly in memory rather than local storage), which reopens the door to XSS-based token theft if that storage decision is made carelessly. CSRF and XSS-based token theft are different threats with different root causes, cookie auto-attachment for one, script execution in a trusted origin for the other, and moving to header-based auth trades one for needing to manage the other more carefully, not a free win.

Worked example

Trace the classic transfer-forgery scenario against a server with no CSRF defenses at all:

1. Victim logs into bank.example.com, receives Set-Cookie: session=abc123 with no SameSite restriction.
2. Victim, still logged in, visits attacker.example, which contains: <form action="https://bank.example.com/transfer" method="POST" id="f"><input name="to" value="attacker_account"><input name="amount" value="5000"></form><script>document.getElementById('f').submit()</script>.
3. The browser submits this form to bank.example.com. Per-domain cookie storage means session=abc123 is attached automatically, since the browser does not consider which page triggered the request, only which domain it targets.
4. bank.example.com sees a request with a valid session cookie and processes the transfer.

Now apply all four mitigations and re-trace: with SameSite=Lax on the session cookie, step 3 never attaches the cookie at all for this cross-site POST, and the request arrives unauthenticated. Even if the cookie somehow attached anyway, the server's CSRF-token check (mitigation 1) rejects the request because the attacker's form has no way to include the per-session token that was only ever delivered to the real page. The Origin header check (mitigation 3) independently catches it, since the request's Origin is https://attacker.example, not https://bank.example.com. And the requirement for a custom header (mitigation 4) means the plain HTML form in step 2 could never have satisfied the request shape at all, since forms cannot set arbitrary headers, forcing the attacker toward more complex (and more blockable) techniques.

Trade-offs and pitfalls

• A common mistake is implementing exactly one of these four mitigations and considering CSRF solved; each has a specific gap (SameSite depends on browser enforcement, Origin checking can occasionally be complicated by legitimate proxies, CSRF tokens require correct per-session issuance and validation, custom-header requirements can be bypassed on endpoints that also accept text/plain bodies without careful configuration), so production systems typically layer at least two of these rather than relying on one.
• Allowing state-changing operations via GET is a design mistake independent of CSRF defenses, since the simplest CSRF payload (an image tag) is a GET request and bypasses form-based reasoning entirely.
• Moving to Authorization-header auth removes CSRF but is not a strict security upgrade on its own; it shifts the burden to secure token storage and handling, and a careless implementation (token in local storage, readable by any injected script) can end up more exposed than a well-configured cookie with HttpOnly and SameSite, not less.
• CSRF tokens must be tied to the session and validated server-side on every state-changing request, not merely present; a common shortcut of checking only that "a token field exists" without verifying it matches the session's issued value defeats the purpose entirely.