The OWASP Top 10: the most common web risks: Backend Development (Intermediate)

What OWASP is

OWASP stands for Open Worldwide Application Security Project. It is a non-profit community of security people from many countries. Everything it makes is free: guides, cheat sheets, testing tools and lists.

A vulnerability is a weakness in an app that an attacker can use to do something they should not, like read other people's data. The OWASP Top 10 lists the ten kinds of vulnerability that are found most often and do the most damage in real web apps.

The list is built from data collected from many companies and security testers. It is updated every few years, and names and order can change between editions. Newer editions may merge or rename items, for example giving more weight to the software supply chain (the packages and tools your app is built from). Always check the official OWASP page for the latest edition.

Think of it like this: Think of the checklist a pilot reads before take-off. The pilot is skilled, but the list makes sure nothing common is forgotten. The OWASP Top 10 is that checklist for a web app: it does not cover every possible problem, but it catches the mistakes that cause most break-ins.

The ten risks in simple words

Risk	Simple meaning	One fix
Broken access control	A user can see or change things that belong to someone else, like another person's order	Check on the server, on every request, that this user owns or may use this record
Cryptographic failures	Sensitive data is not protected well: plain-text passwords, no HTTPS, weak old algorithms	Use HTTPS everywhere, hash passwords with bcrypt or Argon2, encrypt sensitive fields
Injection	User input is treated as code, for example inside an SQL query or a shell command	Use parameterised queries and never build commands by joining strings
Insecure design	The plan itself is unsafe, like an OTP with no limit on tries	Think about abuse while designing: limits, approvals, safe defaults
Security misconfiguration	Wrong settings: debug mode on in production, default passwords, open storage buckets	Use a hardened, repeatable setup and review settings before each release
Vulnerable and outdated components	Old libraries or servers with known bugs	Keep dependencies updated and run npm audit or a dependency scanner
Identification and authentication failures	Weak login: no limit on password guesses, sessions that never end	Rate-limit logins, use strong session handling, offer two-factor login
Software and data integrity failures	Code or data is trusted without checking it was not changed, like unsigned updates	Use lock files, trusted package sources and signed builds
Security logging and monitoring failures	Attacks happen but nobody notices	Log logins, failures and admin actions, and set alerts
Server-side request forgery (SSRF)	The server is tricked into fetching a URL the attacker chooses, even internal ones	Allow only known hosts and block internal addresses

Number one in practice: access control

Access control means deciding who may do what. A very common bug: the URL /api/orders/1005 shows order 1005 to anyone who is logged in, even if it belongs to someone else. The fix is one extra check on the server.

javascript

app.get('/api/orders/:id', requireLogin, async (req, res) => {
  const order = await db.getOrder(req.params.id);
  // The important line: is this order really yours?
  if (!order || order.userId !== req.user.id) {
    return res.status(404).json({ error: 'Not found' });
  }
  res.json(order);
});

Checking ownership on every request (runs on a server with Node.js and Express).

Some fixes are just HTTP headers. A header is a small line of extra information sent with every response. Security headers tell the browser to be stricter, for example to use only HTTPS or to refuse scripts from unknown places.

javascript

app.use((req, res, next) => {
  res.set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
  res.set('X-Content-Type-Options', 'nosniff');
  res.set('Content-Security-Policy', "default-src 'self'");
  next();
});

Middleware that adds three common security headers (runs on a server with Node.js and Express). The helmet package can add these for you.

Tip: Use the Top 10 during code review. For each new feature ask: who may use it (access control), what input reaches a query (injection), what is logged, and which packages it adds.

Careful: Hiding a button in the app is not access control. Attackers do not use your app; they send requests straight to your API. Every rule must be checked on the server.

OWASP also publishes free Cheat Sheets: short, practical guides on topics like password storage, sessions and input validation. They are a good next step after this module.

The OWASP Top 10: the most common web risks

Explanation

What OWASP is

The ten risks in simple words

Number one in practice: access control

Watch the lesson

In real life: A college results site

Practice (0/3 done)

Quick quiz

Read more (free)