Cybersecurity glossary
What is a Backend?
Learn what a backend is in web architecture, how it differs from the frontend, which components it usually includes, and which security practices protect APIs and data.
Definition
A backend is the server-side part of a software system that implements business logic, data storage, authentication, and APIs—typically unseen by end users except through the responses it returns to clients.
Why backends matter
Users interact with screens, but trust decisions happen on the server. Prices, permissions, account balances, and audit trails must be enforced where attackers cannot rewrite the code in DevTools.
A backend is that trusted side: APIs, workers, databases, and integrations that turn requests into durable, authorized outcomes. If the backend is weak, a polished UI cannot save the product.
What a typical backend includes
API and application servers
Processes that accept HTTP, gRPC, or message-driven work and run business logic.
Data stores
Relational databases, document stores, object storage, and search indexes holding authoritative state.
Auth and session services
Login, token issuance, SSO, MFA, and session revocation that protect identity-bound actions.
Async workers and queues
Background jobs for email, scans, billing reconciliation, and other deferred work.
Caches and rate stores
Redis and similar systems accelerate reads and track quotas without hitting primary databases.
Outbound integrations
Payments, email, object storage, and SaaS APIs that expand the trust boundary.
Not every product has all of these pieces on day one, but production systems accumulate them quickly—and each one becomes part of the attack surface.
How a request reaches backend logic
Client sends a request
A browser, mobile app, or partner system calls an HTTPS endpoint with credentials and a payload.
Edge and gateway layers apply policy
CDN, reverse proxy, WAF, or API gateway may terminate TLS, route, rate-limit, and filter.
Backend authenticates the caller
Sessions, JWTs, mTLS, or API keys establish identity before sensitive work begins.
Authorization and validation run
The service checks permissions and parses input against schemas and business rules.
State changes or queries execute
Databases, caches, and external APIs perform the durable side effects of the operation.
A response and audit trail return
The client receives a status and body; logs and metrics capture enough detail to investigate later.
Backend vs frontend
| Aspect | Frontend | Backend |
|---|---|---|
| Runs where | Browser, mobile app, or desktop client | Servers, containers, or serverless platforms |
| Primary job | Presentation and local interaction | Trusted logic, data, and integrations |
| Can hold secrets? | No — anything shipped to clients is exposed | Yes — with vaults, IAM, and rotation |
| Enforces access control | UX only; never authoritative | Must be authoritative on every request |
A useful rule: if skipping the UI and calling the API directly would bypass a control, that control was never really enforced.
Backend security priorities
Authoritative access control
Check object-level and function-level permissions on the server for every sensitive operation.
Input and output handling
Prevent injection and unsafe deserialization; encode outputs appropriately for each sink.
Secrets and configuration
Keep keys out of images and repos; prefer short-lived credentials and least privilege IAM.
Dependency and supply chain hygiene
Patch libraries, pin versions, and watch for malicious packages in CI.
Least-exposed admin surfaces
Debug consoles, Actuator endpoints, and staging APIs must not be casually public.
Resilience against abuse
Rate limits, idempotency, timeouts, and backpressure protect availability and cost.
Backends also face SSRF when they fetch URLs, and privilege escalation when internal service trusts are too broad. Microservices do not remove these problems—they redistribute them.
Operational checklist
- Treat every public and partner API as hostile until authenticated and authorized.
- Centralize authn where practical, but keep authz checks next to each sensitive action.
- Validate request size, content type, and schema before business logic runs.
- Store secrets in a vault or cloud secret manager; rotate and audit access.
- Disable or protect default admin, metrics, and debug endpoints in production.
- Apply rate limits and abuse detection on login, reset, and expensive write paths.
- Log identity, route, outcome, and correlation IDs without storing raw passwords or full card data.
- Review outbound network egress so compromised backends cannot freely scan the internet or cloud metadata.
- Test authorization with negative cases (IDOR) as thoroughly as happy-path features.
The practical takeaway
A backend is the trusted server-side system that owns business rules, data, and integrations. Frontends improve usability; backends decide what is allowed.
Design backends as security boundaries: authenticate callers, authorize actions, validate inputs, protect secrets, and assume direct API access. When those controls are solid, the rest of the stack has a dependable core to protect.
Related security terms
Frontend
The client-facing UI layer that typically calls the backend over HTTP or similar protocols.
Representational State Transfer (REST)
A common style for designing backend HTTP APIs.
Microservices
An architecture that splits backend capabilities into independently deployable services.
Web Application Firewall (WAF)
An edge control that filters hostile traffic before it reaches backend apps.
Broken Authentication
A frequent backend failure mode when login and session controls are weak.
Frequently asked questions
What is a backend in simple terms?
It is the part of an app that runs on servers: it checks who you are, applies business rules, talks to databases, and sends answers back to browsers or mobile apps.
Is the backend only a database?
No. Databases are one component. Backends also include API servers, workers, caches, auth services, and integrations with payment or email providers.
Do serverless functions count as a backend?
Yes. If code runs in response to requests or events and enforces server-side rules, it is still backend logic—even without a long-lived server you manage.
What language is used for backends?
Many: Java, Go, Python, Node.js, Ruby, .NET, and others. The security principles—authz, validation, secrets handling—matter more than the language choice.
Can users see backend code?
Not if it stays on the server. Only responses and public assets are visible. Never put secrets or privileged logic only in the frontend.
What is a BFF (Backend for Frontend)?
A backend tailored to one client type (web, iOS, Android) that aggregates and shapes APIs so the UI does not call every internal service directly.
How do backends get compromised?
Common paths include injection, broken access control, leaked secrets, dependency flaws, SSRF, and misconfigured admin or debug endpoints.
References
Explore authoritative guidance and frameworks related to backend.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.