Security basics every developer must know: the OWASP Top 10, simply explained

The ten most critical web application security risks from the OWASP Top 10:2025, each with a plain example and the fix, plus the everyday habits that prevent most problems.

The OWASP Top 10 is a widely used list of the most critical security risks to web applications. The 2025 edition starts with broken access control, security misconfiguration and software supply chain failures. Most of these risks are prevented by a few habits: check permissions on the server, validate input, keep dependencies updated, and never trust the client.

Security can feel like a specialist subject, but most real breaches exploit ordinary mistakes that any developer can learn to avoid. This guide walks through each of the ten risks with a plain example and the fix, then sums up the habits that matter most day to day.

What is the OWASP Top 10?

OWASP, the Open Worldwide Application Security Project, is a non-profit community that publishes free security resources. Its Top 10:2025 is described as a standard awareness document for developers and web application security, representing a broad consensus about the most critical security risks to web applications. It is updated every few years, and many companies use it as a baseline for secure development and code review.

What are the ten risks, and how do you prevent them?

A01 Broken Access Control

Example: Changing /invoices/1041 to /invoices/1042 in the address bar shows another customer’s invoice.

Fix: Check on the server, for every request, that this user is allowed this exact record. Deny by default.

A02 Security Misconfiguration

Example: A server left with debug mode on, default passwords or a public storage bucket.

Fix: Harden defaults, turn off debug output in production, and review cloud permissions regularly.

A03 Software Supply Chain Failures

Example: A compromised or outdated package pulled into your app through dependencies.

Fix: Keep dependencies few and updated, use lock files, and scan for known vulnerabilities.

A04 Cryptographic Failures

Example: Passwords stored in plain text, or sensitive data sent without HTTPS.

Fix: Use HTTPS everywhere, hash passwords with a proper algorithm, and never invent your own crypto.

A05 Injection

Example: User input pasted straight into a SQL query lets an attacker read or delete the database.

Fix: Use parameterised queries or an ORM, and validate and encode all input and output.

A06 Insecure Design

Example: A password reset that relies on a guessable security question.

Fix: Think about misuse while designing: threat modelling, rate limits and secure patterns from the start.

A07 Authentication Failures

Example: Unlimited login attempts, weak passwords allowed, sessions that never expire.

Fix: Rate-limit logins, support multi-factor authentication and manage sessions carefully.

A08 Software or Data Integrity Failures

Example: An update or data file accepted without checking it came from a trusted source.

Fix: Verify signatures and integrity of updates, packages and critical data.

A09 Security Logging and Alerting Failures

Example: An attack goes on for weeks because nothing was logged or nobody was alerted.

Fix: Log security-relevant events, never log secrets, and alert on suspicious patterns.

A10 Mishandling of Exceptional Conditions

Example: An error message leaks a stack trace, or a failure leaves the system in an unsafe state.

Fix: Handle errors deliberately, fail safely, and show users generic messages.

What does the whole list look like at a glance?

What does injection look like in code?

Injection is the classic example, so it is worth seeing once. This is unsafe, because user input becomes part of the SQL command:

# Unsafe: never do this
query = "SELECT * FROM users WHERE email = '" + email + "'"

This is safe, because the database treats the input strictly as data:

# Safe: parameterised query
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

The same principle applies everywhere: keep instructions and data separate.

Which everyday habits prevent most problems?

What about AI and LLM applications?

If you build features on language models, there is a separate list for those risks, starting with prompt injection. Our article on why companies want engineers who understand models covers the OWASP Top 10 for LLM Applications and why defending against it needs real engineering.

How do you run a basic security check on your own project?

You do not need special tools to start. Take one of your own projects and work through these questions:

Fix what you find, note it in your README, and you have both a safer project and a strong interview story. Repeat the check whenever you add a major feature.

How can you keep learning security?

Read the official OWASP Top 10:2025 pages for each risk, and use the free OWASP Cheat Sheet Series, which gives concise, practical guidance on topics such as authentication, password storage and input validation. Then audit one of your own projects against the list; you will almost certainly find something to fix.

In Program Zero, Phase 11 covers application, network, data and AI security, including the OWASP Top 10, encryption and hashing, secure authentication, API security and prompt injection defences, and ends with a security audit and hardening of your own capstone. More about the programme is on the Program Zero website.

Frequently asked questions

Related reading