Backend security encompasses the server-side measures and coding practices that protect application data, infrastructure, and business logic from unauthorized access and malicious exploitation. It sits at the critical junction where user input meets sensitive data stores, authentication systems, and core application workflows—making it the primary defense layer against injection attacks, privilege escalation, and data breaches. The OWASP API Security Top 10 (2023) and the updated OWASP Web Top 10:2025 provide the foundational frameworks, but modern backend security extends far beyond preventing SQL injection: it requires layered defenses spanning input validation, cryptographic implementation, secrets management, container hardening, and continuous monitoring. One key insight often overlooked: security failures typically cluster around trust boundaries—wherever user input crosses into privileged operations, wherever external services interact with internal systems, and wherever authentication state transitions from unauthenticated to authenticated. Effective backend security means treating every boundary as hostile territory and never trusting data simply because it arrived from an "internal" source.
What This Cheat Sheet Covers
This topic spans 37 focused tables and 261 indexed concepts, 253 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 lists the most critical risks specific to APIs—not the same as the general web application list. APIs expose unique attack surfaces around object authorization, resource consumption, and unsafe upstream data that web apps often don't share.
| Risk | Example | Description | |
|---|---|---|---|
GET /api/users/123/profile accessible by changing ID to /124/ | • Most critical API vulnerability • attackers manipulate object IDs to access unauthorized resources—occurs when authorization checks validate user identity but not ownership of specific objects. | ||
POST /login without rate limiting or MFA | Weak authentication mechanisms allow credential stuffing, session hijacking, or token theft—includes missing brute force protection, predictable tokens, and inadequate password policies. | ||
PATCH /users/me {"isAdmin": true} succeeds | Mass assignment vulnerability where APIs allow users to modify properties they shouldn't access—attackers send extra parameters to elevate privileges or read sensitive fields. | ||
No rate limit on /api/search causing DoS | APIs lacking resource quotas allow attackers to exhaust memory, CPU, or bandwidth through excessive requests or deeply nested queries—especially critical for GraphQL endpoints. | ||
DELETE /admin/users accessible to regular users | • Endpoints lack function-level access control • attackers invoke privileged operations by guessing URLs or manipulating HTTP methods—enforce authorization on every function, not just entry points. | ||
Automated bot scalps concert tickets via /purchase | Business logic vulnerabilities where attackers automate sensitive workflows (purchases, voting, reservations) without proper rate limiting or bot detection—requires behavioral analysis. | ||
/fetch?url=http://169.254.169.254/metadata | Server makes unvalidated requests to attacker-controlled URLs—exploited to access internal services, cloud metadata endpoints, or bypass firewalls by pivoting through the server. | ||
Default admin credentials still active, CORS * wildcard | Improperly configured security settings: default credentials, unnecessary features enabled, verbose error messages, missing security headers, or overly permissive CORS policies. | ||
Old API version v1 still active with known vulnerabilities | Deprecated or undocumented API endpoints remain accessible—attackers target old versions lacking security patches or forgotten shadow APIs with weaker controls. | ||
Trusting third-party API responses without validation | • Applications blindly trust data from external APIs or webhooks—attackers compromise upstream services to inject malicious payloads • always validate and sanitize external data. |