Overview
What It Is
Security in frontend system design means building the application in a way that protects user data, prevents unauthorized actions, and keeps communication with backend services safe.
Even though frontend code runs in the user's browser, it is often the first area attackers try to target.
Frontend Security = Protect users, data, actions, communication, and resources
Why It Matters
A frontend application directly interacts with users, browsers, APIs, storage, third-party scripts, and backend services.
If security is weak, attackers may be able to:
- inject malicious JavaScript
- steal sessions
- manipulate data
- trigger unauthorized actions
- misuse browser storage
- tamper with loaded resources
- abuse poorly configured cross-origin access
Frontend security is not one feature.
It is a collection of safe practices working together.
Main Security Areas
Frontend security covers multiple concepts.
| Area | Main Purpose |
|---|---|
| XSS | Prevent malicious JavaScript injection |
| CSRF | Prevent unwanted authenticated actions |
| Authentication | Verify user identity |
| Authorization | Control resource access |
| Input Validation | Reject invalid or unsafe input |
| Sanitization | Clean unsafe user input |
| HTTPS | Encrypt client-server communication |
| Security Headers | Add browser-level protection |
| Iframe Protection | Prevent clickjacking |
| Dependency Security | Avoid vulnerable packages |
| Client Storage Security | Avoid unsafe storage of sensitive data |
| Compliance | Follow privacy and security regulations |
| SSRF | Understand risks in API integration design |
| SSJI | Prevent server-side JavaScript execution from untrusted input |
| Feature Flags | Roll out features safely |
| SRI | Verify external script and stylesheet integrity |
| CORS | Control cross-origin access |
XSS
XSS stands for Cross-Site Scripting.
It happens when attackers inject malicious JavaScript into a web application.
Possible impact:
- session theft
- data manipulation
- unauthorized actions
Common prevention methods:
- input sanitization
- output encoding
- Content Security Policy
XSS = Attacker injects JavaScript into the app
CSRF
CSRF stands for Cross-Site Request Forgery.
It tricks authenticated users into performing unwanted actions.
Example idea:
User is logged in
Attacker tricks user into making an unwanted request
Server treats it as an authenticated action
Common mitigation methods:
- CSRF tokens
- SameSite cookies
- proper authentication mechanisms
CSRF = Authenticated user is tricked into doing something they did not intend
Authentication and Authorization
Authentication and authorization are related, but they are not the same.
| Concept | Meaning |
|---|---|
| Authentication | Verifies who the user is |
| Authorization | Decides what the user can access |
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
They should be implemented securely using:
- tokens
- sessions
- role-based access control
Input Validation and Sanitization
User input should not be trusted blindly.
All user inputs should be validated and sanitized before being processed or displayed.
Validation checks whether data is acceptable.
Sanitization cleans unsafe content.
Validation = Is this input allowed?
Sanitization = Clean unsafe parts before use
This helps prevent:
- XSS
- injection attacks
- malformed data
HTTPS
HTTPS encrypts communication between the client and the server.
It protects sensitive information from interception and tampering while data travels over the network.
HTTPS = Encrypted communication between browser and server
Use HTTPS when the application sends or receives sensitive data.
It is a basic requirement for secure communication.
Security Headers
Security headers add extra browser-level protection.
Important headers include:
| Header | Purpose |
|---|---|
| Content-Security-Policy | Helps control what resources can run or load |
| X-Frame-Options | Helps prevent framing-based attacks |
| Strict-Transport-Security | Enforces HTTPS usage |
| X-Content-Type-Options | Helps prevent MIME type sniffing issues |
Security headers do not replace secure coding.
They add another defensive layer.
Security Headers = Browser-level safety rules
Iframe Protection
Iframe protection helps prevent clickjacking attacks.
Clickjacking happens when attackers trick users into clicking something hidden or disguised inside a framed page.
Common protection methods:
- X-Frame-Options
- CSP frame directives
Iframe Protection = Stop unauthorized framing and clickjacking risk
Dependency Security
Frontend apps rely heavily on third-party packages.
If dependencies are vulnerable, the application may become vulnerable too.
Important practices:
- audit dependencies regularly
- update vulnerable packages
- review third-party package usage
Dependency Security = Keep third-party packages safe and updated
Client Storage Security
Frontend applications often store data in browser storage.
Sensitive data should not be stored unnecessarily in Local Storage.
For authentication tokens, secure HttpOnly cookies are preferred.
Client Storage Security = Store only what is needed and avoid exposing sensitive data
Unsafe client-side storage can increase risk if JavaScript is compromised.
Compliance and Regulations
Some applications need to follow privacy and security regulations.
Examples:
- GDPR
- CCPA
- PCI-DSS
Compliance helps ensure proper handling of user privacy and sensitive information.
Compliance = Follow required rules for privacy, security, and sensitive data handling
SSRF
SSRF stands for Server-Side Request Forgery.
It happens when an attacker tricks the server into making unintended requests.
Frontend developers should understand SSRF risks when designing API integrations.
SSRF = Attacker influences server to request something unintended
This matters because frontend choices often affect how APIs are called and integrated.
SSJI
SSJI stands for Server-Side JavaScript Injection.
It happens when untrusted input is executed on the server.
Common prevention methods:
- strict input validation
- secure coding practices
SSJI = Untrusted input becomes executable server-side JavaScript
Feature Flags
Feature flags allow safe rollout of new features.
They help teams control whether a feature is enabled or disabled without fully redeploying the application.
Useful for:
- controlled deployment
- gradual rollout
- quick rollback
- reducing release risk
Feature Flags = Safer release control for frontend features
Subresource Integrity
SRI stands for Subresource Integrity.
It ensures externally loaded scripts and stylesheets have not been tampered with.
SRI uses cryptographic hashes to verify resource integrity.
SRI = Browser verifies external resource before using it
This is useful when loading third-party scripts or stylesheets.
CORS
CORS stands for Cross-Origin Resource Sharing.
It controls which domains can access application resources.
Proper CORS configuration helps prevent unauthorized cross-origin requests.
CORS = Rules for which origins can access resources
CORS should be configured carefully because overly open access can create security risk.
Security Overview Table
| Concept | Main Risk | Main Protection |
|---|---|---|
| XSS | Malicious JavaScript injection | Sanitization, encoding, CSP |
| CSRF | Unwanted authenticated actions | CSRF tokens, SameSite cookies |
| Authentication | Fake or invalid identity | Secure tokens or sessions |
| Authorization | Unauthorized resource access | Role-based access control |
| Input Validation | Unsafe or malformed input | Validate and sanitize inputs |
| HTTPS | Interception or tampering | Encrypted communication |
| Security Headers | Browser-level attacks | CSP, HSTS, X-Frame-Options |
| Iframe Protection | Clickjacking | X-Frame-Options, frame directives |
| Dependency Security | Vulnerable packages | Audit and update dependencies |
| Client Storage | Sensitive data exposure | Avoid Local Storage for secrets |
| Compliance | Privacy or legal risk | GDPR, CCPA, PCI-DSS alignment |
| SSRF | Unintended server requests | Careful API integration design |
| SSJI | Server-side code injection | Strict validation and secure coding |
| Feature Flags | Risky release rollout | Controlled deployment and rollback |
| SRI | Tampered external resources | Cryptographic hash verification |
| CORS | Unauthorized cross-origin access | Proper origin configuration |
Basic Checklist
Prevent XSS with sanitization, output encoding, and CSP
Protect against CSRF using tokens and SameSite cookies
Separate authentication from authorization
Use role-based access control where needed
Validate and sanitize all user inputs
Use HTTPS for secure communication
Add important security headers
Protect pages from unsafe iframe embedding
Audit and update frontend dependencies
Avoid storing sensitive data in Local Storage
Prefer secure HttpOnly cookies for authentication tokens
Understand SSRF risks in API integrations
Prevent SSJI with strict validation and secure coding
Use feature flags for controlled rollout and rollback
Use SRI for external scripts and stylesheets
Configure CORS carefully
Follow privacy and security regulations where required
Interview Style Answer
Security in frontend system design means protecting users, data, communication, and application behavior from attacks. Important frontend security topics include XSS, where attackers inject malicious JavaScript; CSRF, where authenticated users are tricked into unwanted actions; authentication and authorization, which verify identity and control access; input validation and sanitization, which prevent unsafe data from entering the system; HTTPS, which encrypts client-server communication; and security headers like CSP, HSTS, X-Frame-Options, and X-Content-Type-Options. Frontend teams also need to consider iframe protection, dependency security, client storage security, compliance, SSRF and SSJI awareness, feature flags, Subresource Integrity, and CORS configuration.
One-Line Summary
Security Overview = Frontend security combines safe coding, secure communication, protected storage, browser defenses, dependency safety, and controlled access.
Final Mental Model
Input -> validate and sanitize
Output -> encode and protect with CSP
Communication -> use HTTPS
Storage -> avoid sensitive client-side storage
Browser -> use security headers
Dependencies -> audit and update
Access -> authenticate and authorize
External resources -> verify with SRI
Cross-origin access -> control with CORS