Overview
Modern web applications are split into a frontend (what runs in the browser) and a backend (what runs on the server). Knowing which code runs where — and who controls it — is essential to reasoning about web security. This lesson explains the split.
Learning objectives
- Distinguish frontend from backend responsibilities.
- Explain why the frontend cannot be trusted for security.
- Identify where sensitive logic and data must reside.
Core concept
- Frontend — HTML, CSS, and JavaScript that run in the user's browser. It renders the interface and handles interaction. It is fully visible and modifiable by the user.
- Backend — code running on the server (application logic, databases, authentication). It is not directly visible to users and is where trust can be enforced.
The dividing line matters: anything on the frontend is public and controllable, while the backend is where secrets, real validation, and authorization must live.
How it works
The frontend sends requests to the backend, which does the authoritative work and returns results. Because frontend code is downloaded to the browser, users can read its source, alter it, or ignore it entirely and talk to the backend directly. Therefore the backend must never rely on the frontend to enforce security — it must re-check authentication, authorization, and input validity for every request as if the frontend did nothing.
Practical example
An e-commerce site might hide a "delete user" button in the frontend for non-admins. But if the backend endpoint that deletes users does not itself verify the requester is an admin, an attacker can call it directly — the hidden button provided no real protection. The security decision must be enforced in the backend, not by omitting a button in the frontend.
Cybersecurity relevance
Confusing frontend concealment with backend enforcement is a classic source of vulnerabilities (e.g. broken access control). Secrets embedded in frontend code (API keys, credentials) are exposed to everyone. Real authorization, validation, and sensitive logic must be server-side. This frontend/backend distinction directly informs later lessons on authentication, authorization, and injection — all of which are backend responsibilities.
Common mistakes
- Embedding secrets (API keys, credentials) in frontend code, where anyone can read them.
- Hiding functionality in the UI and assuming it is protected, without backend enforcement.
- Trusting frontend-computed values (prices, roles) instead of recomputing/verifying on the backend.
Key takeaways
- Frontend code runs in the browser (public, user-controllable); backend code runs on the server (where trust is enforced).
- Never rely on the frontend for security — it can be read, modified, or bypassed.
- Secrets, real validation, and authorization must live in the backend and be re-checked on every request.
Check your understanding
- Why is it unsafe to store an API key or credential in frontend JavaScript?
- Why must access-control decisions be enforced in the backend rather than by hiding UI elements?