Owasp Top Ten: What Web Engineers Should Know

I only became properly aware of the OWASP Top Ten recently.

That is a slightly uncomfortable sentence to write. I have worked on serious customer‑facing web platforms for years, and I have spent plenty of time thinking about authentication, redirects, exposed configuration, content workflows, third‑party scripts, dependency updates, and production failure modes. I knew many of the risks in isolation.

What I had not done was treat the OWASP Top Ten as a named framework that should be part of my ordinary web platform vocabulary.

That feels like a gap worth correcting. Not because I now want to pretend to be a long‑standing application security specialist. I don't. The useful part is almost the opposite. The OWASP Top Ten gives non‑specialist web engineers, technical leads, and platform teams a shared way to talk about risks they may already recognise, but too often discuss too late, too vaguely, or only after something has gone wrong.

What Owasp Gives Us Here

OWASP, the Open Worldwide Application Security Project, is a nonprofit foundation and community around application security. Its output includes projects, standards, testing guidance, cheat sheets, and learning material.

The Top Ten is probably its best‑known document. OWASP describes it as a standard awareness document for developers and web application security, representing broad consensus about critical web application security risks. At the time of writing in late 2024, the relevant edition is OWASP Top 10:2021.

That word "awareness" matters.

The Top Ten is not a complete security programme. It is not a penetration test. It is not a guarantee that an application is safe. It is not a substitute for threat modelling, secure design, code review, dependency management, specialist testing, platform controls, or incident response.

That matters more than it might sound. A shared awareness document gives teams categories, language, and routes into deeper guidance. It does not give teams security by itself, but it does make it easier to ask better questions before launch pressure turns everything into a late‑stage argument.

Why This Matters to Web Engineers

Security can be easy to mentally outsource.

There may be a security team. The API may enforce permissions. The identity provider may handle sign‑in. The hosting platform may manage TLS. The CMS may have roles and workflow. The dependency scanner may run in CI.

All of that helps, but it does not make the web layer irrelevant.

Front‑end and platform teams still shape authentication flows, form handling, client‑side routing, preview URLs, CMS permissions, rendered untrusted content, third‑party tags, analytics scripts, package dependencies, deployment configuration, headers, redirects, logging signals, and error surfaces. Even when the strongest controls live server‑side, the web application is often where the assumptions become visible.

The article I wrote about authentication in Next.js makes a similar point at a smaller scale: authentication and authorisation are related, but not interchangeable. Getting a user signed in is not the same as proving that every protected action is properly constrained.

That is the sort of distinction the OWASP Top Ten helps keep in the conversation.

The 2021 List in Normal Delivery Language

The OWASP Top 10:2021 introduction says that the 2021 version introduced three new categories, changed the naming or scope of four categories, and consolidated some of the older list. It also moved Broken Access Control to the top position.

Here is how I translate the 2021 categories into ordinary production concerns.

Broken Access Control

Broken access control is about users being able to do things outside their intended permissions.

In web platform terms, that means not trusting that a hidden button, disabled form control, client‑side route guard, or absent navigation item is a permission boundary. It also means checking that APIs enforce ownership and roles, not just that the UI makes the wrong path hard to find. Those checks have to happen in trusted server‑side code or APIs; the client can make the flow clearer, but it cannot be the control.

OWASP's Broken Access Control page calls out examples such as URL tampering, missing access controls for write operations, elevation of privilege, token manipulation, and CORS misconfiguration. My older article on CORS and blocked JavaScript fetch requests is useful background for the browser behaviour, but the permission question still belongs on the server. This should feel close to normal web work, not distant security theatre.

Cryptographic Failures

The 2021 list renamed the old "Sensitive Data Exposure" category to Cryptographic Failures, because exposure is often the symptom rather than the root cause.

Most front‑end engineers should not be designing cryptographic systems. That is not the job. But we do need to know when sensitive data is being moved, cached, logged, stored, rendered, or exposed to browser APIs. We should notice when a password reset flow leaks too much information, when a token appears in a URL, when sensitive responses are cached, or when a supposedly private admin route is treated like ordinary content.

This category keeps a common shortcut honest: "the site uses HTTPS" is not the same as "the data is handled safely".

Injection

Injection is not only a database story.

OWASP's Injection category includes classic query injection concerns, and in the 2021 edition it also includes cross‑site scripting. The front‑end and CMS layers have their own ways to make untrusted input dangerous. Search fields, rich text, markdown, embedded HTML, template strings, analytics parameters, internal tools, and content imports can all become part of an injection problem if nobody is clear about validation, encoding, sanitisation, and rendering boundaries.

That is why I care about rendered output, not only source templates. The article on why view source stopped being enough was written for SEO and rendering checks, but the habit carries over here too. The browser‑visible document is where a lot of assumptions finally show themselves.

Insecure Design

Insecure design is the category that made me stop and think.

OWASP introduced Insecure Design as a 2021 category for design flaws. That matters because some security problems are not caused by a bad implementation of a good design. Sometimes the required control was never designed in.

That maps directly to delivery work. Who can preview unpublished content? Who can approve redirects? Can an editor publish a noindex page into primary navigation? Can a user change account state through a route nobody modelled? What happens when the CMS sends unexpected data? Which services are trusted to call which internal endpoints?

These are design questions before they are testing questions.

Security Misconfiguration

Misconfiguration is where web teams should feel immediately implicated.

Headers, redirects, environment variables, preview domains, deployment permissions, error pages, source maps, stale admin routes, cloud storage permissions, overly broad CORS rules, and forgotten staging URLs all sit close to everyday platform work.

The Security Misconfiguration category is a good counterweight to the idea that security risk only lives in clever attack payloads. Sometimes the problem is that a default stayed default, a temporary exception became permanent, or nobody owned the deployment surface after launch.

Vulnerable and Outdated Components

This one should be uncomfortable for anyone who has maintained a long‑lived JavaScript application.

OWASP's Vulnerable and Outdated Components category includes both client‑side and server‑side components, direct dependencies, and nested dependencies. It asks whether teams know what they use, whether they scan and monitor for vulnerabilities, and whether they update in a risk‑based and timely way.

I do not read that as blindly updating everything the minute a tool shouts. It means dependency hygiene is part of operating the platform, not a spring‑cleaning task for when the build finally breaks.

Identification and Authentication Failures

Sign‑in flows carry more risk than the happy‑path demo suggests.

The Identification and Authentication Failures category covers weaknesses around identity, authentication, and session management. In production web work, that means failed‑login behaviour, account recovery, session expiry, cookie handling, multi‑factor authentication, token placement, provider callback URLs, and logout behaviour.

This is also where front‑end and back‑end responsibilities can blur. The UI may not own the identity provider, but it absolutely shapes the user's route through it. It still helps to keep the distinction clear: authentication proves who the user is, whilst authorisation decides what that user may do.

Software and Data Integrity Failures

This category covers trust in code, data, updates, and pipelines.

For web teams, Software and Data Integrity Failures points towards package provenance, build pipelines, deployment automation, unsigned or untrusted updates, CMS data imports, webhooks, and third‑party scripts.

A modern website is rarely just "our code". It is packages, hosted services, scripts, content APIs, build systems, edge configuration, and deployment hooks. Integrity is the question of whether those pieces can be trusted and whether the team would notice if that trust was misplaced.

Security Logging and Monitoring Failures

The category name sounds operational, but it starts earlier than operations.

If access‑control failures, authentication spikes, suspicious form submissions, dependency warnings, webhook failures, or unusual API errors are invisible, the team is relying on luck. OWASP's Security Logging and Monitoring Failures category is a reminder that detection is part of the system.

For web engineers, that does not mean logging everything. It means leaving enough high‑signal evidence to understand whether something important is failing or being abused, without dumping secrets or personal data into logs.

Server‑Side Request Forgery

Server‑side request forgery appears as A10 in the 2021 list.

It is easy for front‑end specialists to assume this is someone else's problem, and often the direct fix will be server‑side. But web teams still create features that fetch remote URLs, import images, generate previews, pull Open Graph metadata, proxy API calls, validate webhooks, or let editors reference external resources. Those are exactly the kinds of product features where the question "what can this server be tricked into requesting?" should come up early.

Not every project needs a long security workshop for that. It does need someone willing to ask the question before the feature is already considered done.

How I Would Use the Top Ten in Delivery

I would not turn every project kickoff into an OWASP ceremony.

The practical move is smaller and more repeatable. Keep the categories nearby when shaping requirements, reviewing architecture, or planning risky features. Ask which categories are relevant to the change in front of the team.

For a CMS‑driven website, I would put it beside the content model and preview workflow discussion. I would ask about preview access, editorial roles, rich‑text rendering, redirects, metadata controls, file uploads, and unpublished content. The older article on planning content models for a headless CMS already argues that content models are technical decisions, and the article on Preview Mode in Next.js with a headless CMS shows how preview flows become application behaviour. The Top Ten adds another lens: which content decisions create security assumptions?

For an authenticated product area, I would ask where identity is established, where authorisation is enforced, how session state is stored, what happens on logout, and whether the UI implies permissions the server does not enforce.

For a marketing or e‑commerce platform, I would ask about third‑party tags, analytics scripts, consent tools, redirects, forms, environment variables, headers, dependency ownership, and deployment access.

For a Next.js or server‑rendered application, I would ask where data is fetched, cached, revalidated, logged, and exposed to the browser. The route may look like front‑end work, but the security questions often cross rendering, API, deployment, and content boundaries.

That is the value. The Top Ten does not answer every question. It makes it harder to forget the obvious ones.

The Top Ten is Not a Checklist

The name is slightly dangerous because "Top Ten" can sound like a checklist. I do not think that is the best way to use it.

It is better treated as a vocabulary and awareness layer. Once a risk looks relevant, the next step is more specific guidance. OWASP has that too: the Application Security Verification Standard for verification requirements, the Web Security Testing Guide for testing practice, and the Cheat Sheet Series for focused guidance on individual topics.

The categories also map to underlying weakness types. The MITRE CWE project is useful context here because it gives names and identifiers to common software and hardware weaknesses. That is a different level of detail from a delivery conversation, but it explains why OWASP categories are broader than individual bugs.

NIST's Secure Software Development Framework makes the broader process point as well: secure development practices need to be integrated into the software development life cycle, not bolted on after the design and delivery decisions have already been made.

What Changes for Me

The immediate change is not dramatic.

I am not suddenly going to sell myself as an application security specialist. I am going to keep the OWASP Top Ten closer to normal engineering judgement.

If a project has authentication, I want the access‑control conversation earlier. If a CMS renders rich text, I want the sanitisation and preview boundaries named. If a platform depends on third‑party scripts, I want ownership and monitoring visible. If a deployment relies on a pile of environment variables and defaults, I want someone to know which ones matter. If a team says "the API handles security", I want to understand what that actually means.

That is a modest use of the framework, but it is worth having.

Wrapping Up

Finding the OWASP Top Ten late is uncomfortable. I would rather have had it as part of my platform vocabulary earlier.

But that is also why it is worth writing about. A lot of experienced web engineers already know fragments of this list through production work: broken permissions, weak session assumptions, exposed secrets, unsafe redirects, fragile CMS preview flows, dependency warnings, third‑party scripts, and logs that are too thin when something odd happens.

OWASP gives those fragments a shared structure.

That structure will not make a project secure by itself. It will make it easier to raise the right concerns early, involve specialists at the right moments, and stop treating security as a final‑stage pass or fail exercise.

For web teams responsible for real production systems, that is already a worthwhile improvement.