Q276: Secure Architecture Review for Frontend Features

What Interviewers Want To Evaluate

Interviewers want to know whether you can review a frontend feature before it becomes expensive to change.

They are testing whether you can identify security, privacy, performance, reliability, accessibility, and operational risks from an architecture proposal.

They also want to see whether your review style is pragmatic rather than fear-driven.

Short Interview Answer

A secure frontend architecture review checks the feature's data, actors, trust boundaries, browser APIs, server APIs, storage, logging, third-party code, failure states, and rollback plan. I ask what the feature exposes, who can access it, what must be enforced server-side, what is stored in the browser, what gets logged, what external scripts or embeds are involved, and how abuse or incident response works. The goal is to shape the design early so safe paths are simple and risky decisions are explicit.

Detailed Interview Answer

Architecture review is most valuable before code is fully built.

At that point, the team can still choose:

same-origin API or third-party API
server session or browser token
iframe or script
public cache or private cache
local state or server state
direct upload or signed upload

These decisions are harder to undo later.

Review Inputs

Start with a clear feature brief.

Ask for:

user workflow
data involved
API endpoints
storage plan
auth model
third-party dependencies
logging plan
failure states
deployment plan

If the team cannot describe these, the feature is not ready for security review.

Data Classification

Identify data categories:

public content
personal data
private user content
secrets
payments
admin-only data
analytics metadata
generated files

Data classification drives storage, caching, logging, and access control.

For example, public handbook content can be CDN cached.

Private user notes should not be cached publicly.

Trust Boundaries

Name every boundary:

browser to server
frontend to identity provider
app to third-party script
parent to iframe
server to object storage
client storage to server state
logs to observability vendor

Then ask what validates data at each boundary.

The browser can help, but server-side checks enforce final decisions.

Authorization Review

Authorization review asks:

what roles exist?
who owns each object?
what can anonymous users access?
what can authenticated users access?
what can admins access?
what happens with expired or revoked sessions?

Do not accept "the button is hidden" as an authorization answer.

Direct URLs and direct API calls must still be safe.

Browser Storage Review

For anything stored in the browser, ask:

why store it?
how sensitive is it?
how long should it live?
does logout clear it?
can XSS read it?
can it be synced safely?
what happens across tabs?

Prefer minimal, scoped, revocable state.

Third-Party Review

Third-party code deserves explicit attention.

Ask:

does it run as script or iframe?
what data can it read?
what routes load it?
does CSP allow it?
does it affect performance?
who owns the vendor relationship?
how do we disable it during incident?

This review often reveals unnecessary broad access.

Logging and Privacy Review

Ask:

what events are logged?
are fields allowlisted?
are tokens redacted?
are query strings scrubbed?
is session replay enabled?
what is retention?
who can access the data?

Debugging should not become data collection without boundaries.

Failure and Rollback

Secure features still fail.

Review:

network failure
auth failure
permission denied
rate limit
third-party outage
partial upload
stale cache
incident disable switch
rollback path

The best designs fail safely and clearly.

Interview Example

If asked, "Review a new AI mock interview feature for this app," say:

classify prompts and responses
avoid logging private answer content casually
keep provider API keys server-side
rate-limit expensive calls
define retention
show clear loading and failure states
review third-party data sharing
add abuse cases for prompt injection and sensitive data

That shows broad architecture judgment.

Common Mistakes

Common mistakes include:

reviewing only after implementation
focusing only on XSS
ignoring logs and analytics
not naming trust boundaries
trusting UI-only authorization
letting every team invent storage patterns
not planning incident disable paths
making review too heavy to use

Senior-Level Framing

The senior framing:

"I review frontend architecture by following data and trust. If we know what data exists, where it flows, who can access it, what stores it, and what observes it, we can design safe defaults early."

Practice Prompt

Review a planned cloud progress feature.

Cover:

auth
API design
object ownership
browser storage
offline sync
logging
privacy
abuse cases
rollback

Final Mental Model

Secure architecture review is not a gate at the end.

It is a design conversation that makes risky boundaries visible while the team can still choose the safer path.