Cybersecurity glossary
What is a Frontend?
Learn what a frontend is in web and mobile apps, how it differs from the backend, common architectures, and which client-side security mistakes still matter.
Definition
A frontend is the client-facing layer of an application—typically a web UI, mobile app, or desktop interface—that presents information and captures user actions while relying on backends for authoritative business logic and data.
Why frontends matter
Users judge products by what they can see. The frontend turns API data into understandable screens and turns clicks into requests. It also runs in the most hostile place in the stack: on devices attackers fully control.
That means frontends are essential for usability and important for reducing client-side risk—but they must never be the only place security decisions live.
What a frontend typically includes
Presentation layer
Layouts, components, typography, and accessibility affordances that make features usable.
Client state
UI state, form drafts, cached views, and sometimes offline queues stored in memory or browser storage.
API clients
HTTP, GraphQL, or WebSocket code that fetches and mutates server data.
Client-side routing
Navigation between views in SPAs or hybrid apps without always reloading full documents.
Modern web frontends may be static sites, server-rendered apps, or rich SPAs. The delivery model changes performance and SEO; it does not change the rule that clients are untrusted.
How frontend and backend collaborate
User opens the client
A browser downloads HTML/JS/CSS, or a mobile app launches its UI shell.
Frontend renders an initial view
It may use SSR HTML, cached data, or placeholders while waiting for APIs.
User performs an action
Clicks, form submits, and gestures become events handled by client code.
Client calls the backend
Authenticated requests carry tokens or cookies to APIs that enforce real rules.
Backend returns authoritative results
The frontend displays success, errors, and updated state from the response.
Client-side defenses still apply
Output encoding, CSP, and safe DOM APIs reduce XSS even when data is trusted from your API.
Frontend vs backend responsibilities
| Concern | Frontend role | Backend role |
|---|---|---|
| Access control | Hide unavailable actions for UX | Deny unauthorized operations for real |
| Input checks | Fast validation and helpful errors | Schema and business-rule enforcement |
| Secrets | Only public configuration | Private keys, privileged API credentials |
| Auditability | Optional analytics events | Authoritative security and transaction logs |
Frontend security that still matters
Even with a strong API, client-side flaws create account takeovers and supply-chain incidents.
Stop XSS at render time
Prefer safe templating; avoid `innerHTML` with untrusted strings; sanitize only when necessary and carefully.
Treat storage carefully
Tokens in `localStorage` are easy XSS prey. Prefer HttpOnly cookies for session material when the model fits.
Lock down browser powerful APIs
Use CSP, Trusted Types where available, and careful `postMessage` origin checks.
Verify third-party scripts
Apply SRI, limit tag managers, and review who can publish to your script origins.
Avoid open redirects and unsafe URLs
Do not bounce users to attacker-controlled destinations based on raw query parameters.
Least privilege public clients
Mobile and SPA OAuth clients must use public-client patterns—no embedded client secrets.
Practical checklist
- Assume attackers can modify any frontend code or request before it reaches your API.
- Encode untrusted data for the correct context (HTML, attribute, JS, URL, CSS).
- Ship a strict Content Security Policy and monitor violations in staging.
- Keep privileged secrets off the client; use backend-for-frontend patterns when needed.
- Review dependency update and XSS advisories for UI frameworks and rich-text libraries.
- Protect session cookies with Secure, HttpOnly, and appropriate SameSite settings.
- Test accessibility and error states—confused users are easier to phish.
- Document which security controls are UX-only versus server-enforced.
The practical takeaway
A frontend is the user-facing client layer that presents data and captures intent. It shapes product experience and carries real browser and mobile risks, especially XSS and token exposure.
Build frontends to be resilient and clear—but put authoritative security in the backend. When both layers do their jobs, users get a trustworthy interface on top of trustworthy decisions.
Related security terms
Backend
The server-side counterpart that must enforce trust decisions the frontend cannot.
Cross-Site Scripting (XSS)
A primary frontend risk when untrusted data is rendered as executable code.
Content Security Policy (CSP)
A browser control that reduces the impact of injected scripts.
Cross-Origin Resource Sharing (CORS)
Browser rules that govern which frontends may read responses from an API origin.
Subresource Integrity (SRI)
Protects frontends that load scripts and styles from third-party CDNs.
Frequently asked questions
What is a frontend in simple terms?
It is everything users see and click: pages, buttons, forms, and mobile screens. It talks to servers behind the scenes to load and save real data.
Is HTML/CSS/JavaScript the only frontend?
For the web, those are the core technologies. Mobile and desktop frontends may use native toolkits or cross-platform frameworks, but the security idea is the same: clients are untrusted.
Can frontend code hide secrets?
No. Anything shipped to a browser or app package can be inspected. API keys with privileged access must stay on the server.
What is a single-page application (SPA)?
A frontend that loads a shell once and updates the UI with JavaScript while calling APIs, instead of fetching full new HTML pages for every navigation.
Does a secure frontend mean the app is secure?
No. Frontend hardening helps users and reduces XSS impact, but authorization and validation must still live in the backend.
What is server-side rendering (SSR)?
Generating HTML on a server for faster first paint or SEO, then optionally hydrating interactivity in the browser. SSR blurs deployment lines but does not remove the need for API authz.
Why do frontends still need security reviews?
XSS, open redirects, insecure postMessage usage, dependency compromise, and leaked tokens in local storage remain common incident sources.
References
Explore authoritative guidance and frameworks related to frontend.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.