Q087: Frontend Security Review Process
What Interviewers Want To Evaluate
This question tests whether you can identify and reduce frontend security risk before release. Interviewers want practical review habits around auth, authorization, XSS, CSRF, sensitive data, third-party scripts, dependency risk, browser storage, logging, headers, and threat modeling.
Senior frontend engineers are not expected to replace a security team, but they should know how frontend decisions create or reduce attack surface.
Short Interview Answer
A frontend security review starts by identifying sensitive flows, trust boundaries, user-controlled data, authentication and authorization behavior, storage choices, third-party scripts, dependency changes, logging, and browser security controls. I would review whether permissions are enforced server-side, untrusted content is escaped or sanitized, tokens are stored safely, errors do not leak sensitive data, and security headers such as CSP are aligned with the app. For high-risk changes, I would involve security early and add tests or monitoring where useful.
Detailed Interview Answer
Frontend security is layered. The UI can improve safety, but the server must enforce critical rules. A senior frontend engineer should know where frontend controls help and where they are only usability hints.
Start with a threat-oriented checklist:
What data is sensitive?
Who can access it?
Where does user-controlled input render?
Where are tokens stored?
What third-party scripts run?
What permissions are UI-only?
What gets logged?
What headers protect the page?
What happens on auth expiry?
Trust Boundaries
Trust boundaries are places where data crosses from one authority to another. Examples include API responses, URL parameters, user input, markdown rendering, file uploads, third-party widgets, and postMessage communication.
Frontend code should treat external data as untrusted until validated, escaped, or sanitized according to its usage.
Authorization
Frontend authorization checks are useful for hiding unavailable actions and improving UX. They are not enough for enforcement.
Every sensitive action must be checked on the server. The frontend must also handle denied responses safely because permissions can change while a page is open.
XSS Review
Review any place that renders HTML, markdown, rich text, URLs, or scriptable attributes. Avoid dangerouslySetInnerHTML unless there is a strong reason and sanitization is correct.
Escaping and sanitization depend on context. HTML body, attributes, URLs, CSS, and JavaScript each have different risks.
Storage Review
Browser storage should match sensitivity. LocalStorage is convenient but exposed to JavaScript, so XSS can read it. HttpOnly cookies protect against JavaScript reads but require CSRF-aware design.
Do not store sensitive data longer than necessary. Review cached API data, offline drafts, logs, and downloaded files.
Third-Party Scripts
Third-party scripts can observe or modify pages. Analytics, chat widgets, tag managers, A/B testing tools, and embedded content should be reviewed for necessity, privacy, performance, and failure behavior.
Use CSP, subresource integrity where applicable, consent rules, and isolation patterns when needed.
Dependency Risk
Security review should include package changes. New dependencies can introduce vulnerabilities, install scripts, large transitive graphs, or unmaintained code.
Automated audits are helpful, but teams still need judgment about exploitability and deployment context.
Logging and Privacy
Frontend logs, analytics, session replay, and error reports can leak sensitive data. Review payloads for tokens, emails, addresses, payment details, internal IDs, or personal data.
Masking and allowlists are usually safer than trying to remove sensitive fields after broad capture.
Common Mistakes
A common mistake is assuming that hiding a button enforces authorization. Another is storing tokens in localStorage without discussing XSS risk.
Another mistake is adding rich text or markdown rendering without treating it as untrusted content.
Senior Trade-Offs
Strict security controls can make development slower, but weak controls create product and user risk. The senior answer should show layered defense and risk-based escalation.
Not every change needs a formal security review. Sensitive flows and trust-boundary changes do.
Code or Design Example
A security review checklist can be part of PR templates for high-risk areas.
type FrontendSecurityReview = {
touchesAuth: boolean;
rendersUserContent: boolean;
storesSensitiveData: boolean;
addsThirdPartyScript: boolean;
addsDependency: boolean;
serverAuthorizationVerified: boolean;
logsReviewedForSensitiveData: boolean;
};
This helps reviewers ask the right questions before release.
Production Example
Suppose a feature adds a rich text announcement editor. The frontend must review sanitization, preview rendering, stored HTML, CSP compatibility, image URLs, links, permissions, audit logs, and whether content can be rendered in emails or mobile clients.
This is more than a component task. It is a trust-boundary change.
Working With Security Teams
Involve security early for high-risk changes. Bring context: user flow, data types, architecture diagram, storage choices, third-party scripts, and proposed mitigations.
Security reviews go better when engineers ask specific questions rather than asking for broad approval at the end.
Revision Notes
Frontend security review is about sensitive data, trust boundaries, auth, rendering, storage, third parties, dependencies, logging, headers, and server enforcement.
Key Takeaways
Frontend security is layered. The UI can reduce risk, but sensitive authorization and data protection need server-side enforcement and careful browser decisions.
Follow-Up Questions
- What is a frontend trust boundary?
- Why is UI-only authorization unsafe?
- How do you review XSS risk?
- What storage is appropriate for tokens?
- How do third-party scripts create risk?
- What should not be logged?
- How does CSP help?
- When should security be involved?
- How do dependency changes affect security?
- How do you review rich text rendering?
How I Would Answer This In A Real Interview
I would frame security review around trust boundaries and sensitive flows. I would inspect auth, authorization, untrusted rendering, storage, third-party scripts, dependencies, logging, CSP, and server enforcement, then escalate high-risk changes to security early with clear context.