OWASP Top 10 for Backend Developers

The list below follows the OWASP Top 10 (2021 edition), which is still widely used in training and audits. OWASP also published a newer 2025 edition that reorganises some categories. For example, software supply chain problems (attacks through the code and tools you depend on) get their own category. Another new category covers the mishandling of errors and unusual situations. The ideas below still apply. But check the official OWASP site for the current list and numbering before you publish or audit against it.

A01: Broken Access Control

What it is: access control means rules about who may do what. It is "broken" when users can do or see things they should not:

• reading other users' data by changing an ID (IDOR, post 49: the server does not check who owns the record),
• calling admin endpoints as a normal user,
• modifying a price or role field in a request,
• accessing another tenant's data in a SaaS app. (A tenant is one customer account. SaaS means software that customers use online, like a subscription app.)

It's the #1 risk in the 2021 list.

GET /api/accounts/1002/statement           ← logged in as account 1001… and it works 😱PATCH /api/users/1001  {"role": "admin"}   ← the server blindly saves "role" (mass assignment)

Fixes:

• Check permission on every request, for every object, on the server. Never trust the client (the browser or app), because users can change what it sends.
• Deny by default. Access is refused unless a rule clearly allows it.
• Limit queries to the current user or tenant (WHERE tenant_id = ?). Also consider row-level security, where the database itself hides rows a user may not see.
• Allow-list the fields users can update. An allow-list is a list of what is permitted, and everything else is refused. This avoids "mass assignment", where a request sets fields it should not, like role, price or is_verified.
• Use IDs that are hard to guess (like random UUIDs) as an extra layer, but never as the only protection.
• Test access control with automated tests ("user A cannot read user B's order").

A02: Cryptographic Failures

What it is: sensitive data isn't properly protected:

• sent over plain HTTP (not encrypted),
• stored unencrypted,
• passwords hashed with MD5 or SHA-1,
• weak or hard-coded keys,
• old TLS versions (post 51).

Fixes:

• HTTPS everywhere, with HSTS (a header that tells browsers to always use HTTPS for your site), and TLS between internal services.
• Encrypt sensitive data at rest, with field-level encryption or tokenisation for the most sensitive data.
• Argon2id, bcrypt or scrypt for passwords (post 49).
• Keys in a KMS or secrets manager, and rotated (post 51).
• Don't store what you don't need. Data you never collect can't leak.

A03: Injection

What it is: the app treats input that it should not trust as code or commands. This can be SQL, NoSQL, operating-system commands, LDAP (a directory lookup language) or templates. The 2021 edition also puts cross-site scripting (XSS) here. XSS means an attacker makes their own JavaScript run on your web page.

SQL injection example:

// ❌ Vulnerable: input is glued into the SQL stringconst q = `SELECT * FROM users WHERE email = '${req.body.email}'`;// input:  ' OR '1'='1   → query becomes: ... WHERE email = '' OR '1'='1'  → returns every user

Fixes:

• Parameterised queries and prepared statements, always. This means the SQL text and the user's values are sent to the database separately. ORMs (libraries that let you use the database through code objects) do this by default, but be careful with their "raw query" features.
• Never build shell commands from user input. Use safe library functions, or strict allow-lists.
• Validate input (check its type, length, format and allowed values). Also encode output for the place where it is shown (HTML, URL, JavaScript) to prevent XSS. Encoding turns special characters like < into harmless text. Modern frameworks (React, Angular, template engines) do this by default, so be careful with their "raw HTML" features.
• Least-privilege database accounts: give the app's database user only the permissions it needs. It should not be able to DROP (delete) tables.

A04: Insecure Design

What it is: the design itself is unsafe, even if the code is perfect. For example:

• a password reset that relies on easily guessed "security questions",
• no limits on how many coupons one account can redeem,
• a checkout that trusts the price sent from the browser,
• no rate limit on OTP attempts (an OTP is a one-time password; a rate limit caps how many tries are allowed).

Fixes:

• Threat modelling during design: before you build a feature, ask "how could someone abuse this?"
• Secure design patterns: work out prices on the server, use rate limits (post 43), use idempotency (post 34: repeating a request does not repeat its effect), and ask for an extra login check (step-up authentication) for sensitive actions.
• Abuse-case tests (tests that act like an attacker) next to the normal tests.

A05: Security Misconfiguration

What it is: insecure settings:

• default passwords left unchanged,
• public storage buckets,
• debug mode or detailed stack traces in production,
• open network ports you do not need, and admin panels open to the whole internet,
• CORS settings that are too open (CORS is the browser rule about which websites may call your API; Access-Control-Allow-Origin: * lets any site),
• missing security headers (HTTP headers that tell the browser to apply safety rules).

Fixes:

• Safe, repeatable settings through infrastructure as code (you describe your servers and cloud setup in files). Review these files like application code.
• Disable debug mode, directory listings and default accounts in production.
• Private by default: storage buckets, databases and admin tools are not public (post 17).
• Security headers: Content-Security-Policy (limits which scripts the page may run), Strict-Transport-Security, X-Content-Type-Options: nosniff, and frame-ancestors (or X-Frame-Options).
• Automatic scanning of settings (cloud security tools and Kubernetes policy tools).

A06: Vulnerable and Outdated Components

What it is: using libraries, frameworks, operating systems or containers that have known vulnerabilities. A vulnerability is a weakness that attackers can use. Modern apps contain hundreds of dependencies (libraries they rely on), and one bad one is enough.

Fixes:

• Know what you run: keep a software bill of materials (SBOM). This is a list of every component inside your software, like an ingredients list.
• Automatic dependency scanning (Dependabot, Renovate, Snyk, OSV-Scanner) and container image scanning. These tools compare your libraries with lists of known weaknesses.
• Patch quickly. A patch is an update that fixes a weakness. Be fastest for serious weaknesses that attackers are already using. Have a process to release urgent patches within hours or days.
• Remove unused dependencies, and prefer well-maintained ones.

A07: Identification and Authentication Failures

What it is: weak login and session handling (a session is how the server remembers you after login):

• allowing weak or breached passwords,
• no protection against credential stuffing (attackers trying leaked username/password pairs from other sites),
• no MFA,
• session IDs in URLs,
• sessions that never expire,
• predictable reset tokens.

Fixes (post 49):

• MFA and passkeys; breached-password checks.
• Rate limiting and bot detection on login, OTP and password reset endpoints (post 43).
• Secure session cookies (HttpOnly, Secure, SameSite), session expiry, and new session IDs after login.
• Password-reset tokens that are random, short-lived and usable once.
• Use a proven identity provider or library instead of building auth from scratch.

A08: Software and Data Integrity Failures

What it is: trusting code or data without checking it:

• installing unverified updates or plugins,
• insecure CI/CD pipelines,
• deserialising untrusted data into objects (turning received bytes back into program objects; in some languages this lets an attacker run code on your server, called remote code execution),
• webhooks accepted without checking signatures.

This includes supply-chain attacks, where attackers compromise a dependency or build system to reach many victims at once.

Fixes:

• Check signatures on build outputs (artefacts) and updates, and sign your own builds (for example with Sigstore, a free signing service). Follow frameworks like SLSA, a set of rules for keeping the build process trustworthy.
• Lock dependency versions with lockfiles (files that record the exact versions you use). Use trusted registries (the public stores of packages), and review new dependencies.
• Protect CI/CD (the automatic build and release pipeline): use tokens with few permissions, protected branches, required code reviews, and OIDC instead of long-lived cloud keys (post 51).
• Avoid unsafe deserialisation. Use simple data formats (like JSON) and check them against a schema (a description of the allowed shape).
• Verify webhook signatures (post 34). A webhook is a call that another service sends to your server. A signature made with HMAC (a keyed hash, post 51) proves it is genuine.

A09: Security Logging and Monitoring Failures

What it is: attacks happen and nobody notices, or there are no logs to study afterwards. Breaches often stay hidden for months.

Fixes (posts 46–48):

• Log security events: logins (success and failure), password and MFA changes, permission changes, access denials, admin actions and high-value transactions.
• Collect logs in one place, protect them from changes, and keep them long enough to investigate.
• Alert on suspicious patterns: spikes in failed logins, access from unusual locations, mass data exports.
• Never log secrets or sensitive data (post 51).
• Have an incident response plan (a plan for what to do during an attack) and practise it (post 48).

A10: Server-Side Request Forgery (SSRF)

What it is: the attacker makes your server send requests to places it should not. For example, an attacker abuses a "fetch image from URL" feature to reach internal services or the cloud metadata endpoint. The metadata endpoint is a special address (169.254.169.254) inside a cloud server that tells the server about itself. It can return temporary cloud credentials.

Fixes:

• Allow-list the destinations your server may fetch (domains and schemes).
• Block private and internal IP ranges, including 169.254.169.254, localhost and internal subnets, after DNS resolution. Also re-check after redirects.
• Use IMDSv2 on AWS. This is the newer version of the metadata service, and it needs a session token, so a simple forged request does not work. Use the matching protections on other clouds.
• Run features that fetch URLs in an isolated network or service that cannot reach internal systems.
• Give servers cloud roles with the fewest permissions, so stolen credentials can do very little.

Beyond the Top 10: APIs

OWASP also publishes an API Security Top 10. It matters a lot for backend and mobile systems. Its top risks include:

• broken object-level authorisation (IDOR),
• broken authentication,
• broken object property-level authorisation (exposing or allowing edits to fields users shouldn't touch),
• unrestricted resource consumption (no rate limits and no limits on page size, posts 34 and 43),
• broken function-level authorisation (normal users calling admin functions).

Building security into the process

• Design: threat modelling (asking "what could go wrong?") for new features and designs.
• Code: secure defaults, frameworks that escape output and parameterise queries, and code review.
• CI/CD: static analysis (SAST, a tool that reads your code to find weaknesses), dependency and secret scanning, container scanning, and checks of your infrastructure-as-code files.
• Testing: dynamic scanning (DAST, a tool that attacks your running app to find weaknesses), security unit tests, and penetration testing (hired experts try to break in) for important systems.
• Production: a WAF (web application firewall, which filters bad web requests) as an extra layer, not a replacement for fixing code. Also monitoring, and a bug bounty or responsible-disclosure programme (outsiders report weaknesses to you, and you may pay them).
• People: training (for example, the free PortSwigger Web Security Academy labs), clear owners for security, and blameless incident reviews.