The OWASP Top 10 is a list of the ten most serious security risks in web applications, published by the Open Worldwide Application Security Project (OWASP), a non-profit. This article explains the current edition, the OWASP Top 10 2025, in plain words: what each risk means for a business app, how it goes wrong, what to ask your developers, and where AI-written code makes it more likely.
You don't need to read code to use it. If your business runs on a customer portal, an online shop, an ERP such as Odoo with custom modules, or an app someone built with an AI tool, these ten risks are where most real breaches start.
What the OWASP Top 10 is
OWASP has published the list since 2003 and updates it every few years. The 2025 edition, announced in November 2025, is built on test data from more than 2.8 million applications donated by security companies, plus a survey of practitioners for risks that test data doesn't show well. Each category groups many specific weaknesses (248 in total in this edition), so one heading can cover dozens of ways the same thing goes wrong.
Compared with the 2021 list, two things are new. Software supply chain failures now has its own place at number three, and mishandling of exceptional conditions joins at number ten. Security misconfiguration climbed from fifth to second. Server-side request forgery, a separate entry in 2021, is now part of broken access control.
The OWASP Top 10 2025 in order, with each category in a few words.
The ten risks, one by one
A01:2025 Broken Access Control
Access control decides who can see and change what. It's broken when a user can reach data or actions that belong to someone else. It has held first place since 2021.
A typical case: a customer opens invoice 1043 in your portal, changes the number in the address bar to 1044, and sees another company's invoice. The page checked that the user was logged in but never checked that the invoice was theirs.
// Any logged-in user can read any invoice by changing the number
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
res.json(await db.invoices.findById(req.params.id));
});
// Fixed: the invoice must belong to the user's own company
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
const invoice = await db.invoices.findOne({
id: req.params.id,
companyId: req.user.companyId,
});
if (!invoice) return res.status(404).end();
res.json(invoice);
});In Odoo, the same mistake shows up when custom code runs with sudo(), which skips the access rules your administrators set, and then hands the result to a portal user.
Ask your developers: is every permission checked on the server for every request, or only hidden in the screens? Can you show me a test where one customer tries to open another customer's record? With AI-written code: this gap comes up again and again in published research on AI-built apps. The tool builds the screen you asked for and rarely asks whose data it should show. In 2025, a researcher found 170 apps from Lovable's public showcase whose databases anyone could read or change, because access rules were missing (CVE-2025-48757).
A02:2025 Security Misconfiguration
The software can be sound and still be left open by its settings. Think of default passwords, debug mode switched on in production, admin pages reachable from the internet, cloud storage set to public, or error pages that show the inner workings of the system.
Example: a staging copy of your system, with a real copy of the customer database, is left online with the default admin password because "it's only for testing".
Ask your developers: how do we know production settings are the same every time we deploy? Who checks that test servers and storage buckets aren't public? With AI-written code: tools often pick settings that make things work quickly, such as allowing requests from any website or leaving debug output on. Nobody switches them back unless it's on a checklist.
A03:2025 Software Supply Chain Failures
Modern apps are built mostly from outside parts: open-source packages, plugins, build tools and hosted services. This category covers the risk that one of those parts is outdated, abandoned or deliberately poisoned. In 2025 a self-spreading worm known as Shai-Hulud published malicious versions of hundreds of npm packages, the library store JavaScript developers rely on, and stole the access tokens of the developers who installed them.
Example: your web shop uses a payment plugin nobody has updated in years. A flaw in it is made public, automated attacks follow, and nobody on your side knew the plugin was there.
Ask your developers: do we have a list of every component we use, with its version? How quickly do we apply security updates, and who gets the alerts? With AI-written code: AI tools suggest versions from their training data, which may be old, and sometimes invent package names that don't exist. Attackers register those names and wait. This trick even has a name, slopsquatting, and we cover it in our article on the security risks of AI-generated code.
A04:2025 Cryptographic Failures
Cryptography protects data by scrambling it so only the right people can read it. It fails when sensitive data travels or sits unprotected, when passwords are stored in a form that can be reversed, or when secret keys are kept where others can find them.
Example: a database backup is copied to a shared drive. The passwords inside were stored with an old method (MD5) that can be cracked in minutes, and many of your customers use the same password elsewhere.
Ask your developers: how are passwords stored? Is all traffic encrypted, including between our own servers? Where do secret keys live, and who can read them? With AI-written code: keys pasted straight into the code are common, and older examples the tools learned from still use weak hashing methods.
A05:2025 Injection
Injection happens when text typed by a user is treated as a command. The classic case is SQL injection, where a search box or login form lets someone run their own database query. Cross-site scripting, where a visitor plants code that runs in other users' browsers, belongs here too.
# Unsafe: the search text becomes part of the SQL command
cur.execute(f"SELECT * FROM customers WHERE name LIKE '%{term}%'")
# Safe: the database receives the text only as data
cur.execute("SELECT * FROM customers WHERE name LIKE %s", (f"%{term}%",))A related JavaScript flaw, prototype pollution, lets crafted input change how the whole app behaves; we explain it in prototype pollution in JavaScript.
Ask your developers: do we always use parameterized queries and the framework's own escaping? Is input checked on the server as well as in the form? With AI-written code: quick fixes often build queries by gluing text together, especially in custom reports and search features, so they need a second look.
A06:2025 Insecure Design
Some flaws aren't coding mistakes at all. The feature works exactly as built, but nobody thought about how it could be abused.
Example: a discount code meant for one use per customer can be applied again and again by opening several browser tabs at once. Or a password reset asks a security question whose answer is on the user's social media profile.
Ask your developers: for our most valuable flows (payments, refunds, approvals, account changes), what could a dishonest user try, and what stops them? With AI-written code: the tool builds what the prompt describes. If nobody writes down the abuse cases, they aren't handled.
A07:2025 Authentication Failures
Authentication is how the system knows who you are. It fails when attackers can guess or reuse passwords without limit, when sessions never expire, or when there's no second step such as a code on your phone for sensitive accounts.
Example: an attacker takes a list of leaked emails and passwords from another site and tries them on your portal, thousands per hour. Nothing slows them down, and every reused password opens an account.
Ask your developers: do we limit failed login attempts? Do admins and finance users have two-factor authentication? Do sessions end after logout and after a period of inactivity? With AI-written code: home-made login systems are a risk. A proven login library or provider is usually safer than code generated from scratch.
A08:2025 Software or Data Integrity Failures
This category is about trusting data or updates without checking that they really come from where they claim. It overlaps with the supply chain, but focuses on your own app: unsigned updates, plugins loaded from unknown places, or data from outside accepted as if it were safe.
Example: your shop marks an order as paid when it receives a message from the payment provider. If the app doesn't verify the signature on that message, anyone who finds the address can send a fake "payment received" and get goods for free.
Ask your developers: do we verify every webhook and every update we install? Can anyone change our build or deployment process without a second person seeing it? With AI-written code: signature checks on webhooks are often left out of quick integrations, because the demo works without them.
A09:2025 Security Logging and Alerting Failures
If nobody records and watches what happens in the system, attacks go unnoticed for months. The 2025 edition renamed this category to stress alerting, because logs that nobody reviews don't stop anything.
Example: someone tries a thousand passwords on the admin account overnight and finally gets in. The attempts were logged, but no alert went out, and the breach is discovered weeks later when a customer complains.
Ask your developers: do we log logins, failed logins, permission changes and large transactions? Who gets an alert, and how fast? How long do we keep logs, and can an attacker delete them? With AI-written code: AI tools rarely add audit logs or alerts unless asked, and when they do log, they sometimes record passwords or personal data that shouldn't be there.
A10:2025 Mishandling of Exceptional Conditions
New in 2025. This covers what the app does when something unexpected happens: a service is down, a file is too big, input is in the wrong format, or a step fails halfway. Badly handled errors can crash the system, leak internal details or leave data in a broken state.
Example: a payment flow takes money from one account, then fails before recording it in the other, and doesn't undo the first step. Or an error during a permission check is caught and ignored, and the app carries on as if the check had passed. Security people call this failing open.
Ask your developers: when a step fails in the middle of a transaction, is the whole transaction rolled back? Do error messages to users hide technical details? With AI-written code: generated code often wraps problems in a catch-all that hides the error and keeps going, which makes the app look stable while it does the wrong thing.
How to use the list
OWASP describes the Top 10 as an awareness document. It's a good way to start a conversation with your team or a supplier, to write security into a project's requirements, and to decide where to look first. It isn't a complete standard, and OWASP itself says that using it as a coding or testing standard is the bare minimum.
For deeper checks, OWASP points to its Application Security Verification Standard (ASVS), now at version 5.0. The ASVS turns these topics into hundreds of specific requirements that can be tested, in three levels, so you can match the depth of checking to how sensitive the application is. A portal holding payroll data needs more than a brochure website. OWASP also publishes separate lists for mobile apps and for apps built on large language models.
The Top 10 tells you what to worry about; the ASVS gives you requirements you can test against.
A practical way to start, even if you aren't technical, is to send the ten "ask your developers" questions above to whoever builds or maintains your system and see how clearly they answer. You can also take our free go-live self-check, ten questions that take about two minutes, to see where the basics stand.
What a security review covers
Automated scanners find some of these problems, mostly outdated components, missing settings and simple injection. They can't tell whether a user should be allowed to see a record, whether a discount can be abused, or whether an error leaves your books in a broken state. That takes people who read the code and test the app the way an attacker would.
A useful review looks at the application as a whole: access rules, logins, how data is stored and sent, outside components, settings on the servers, and the business flows that handle money or personal data. For a business owner, the output matters most. You should get a written report that shows each problem with evidence, explains what it could cost, and puts the fixes in order so your team knows what to do first. Your developers should be able to reproduce every finding, so nobody has to take the report on trust.
Frequently asked questions
What is the OWASP Top 10?
It's a list of the ten most serious risks in web applications, published by OWASP, a non-profit foundation. Developers, auditors and buyers use it as a shared starting point for application security.
What changed in the OWASP Top 10 2025?
Two categories are new: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10). Security Misconfiguration moved up to second place, and server-side request forgery is now part of Broken Access Control, which stays first.
Is there an OWASP Top 10 certification or compliance?
No. OWASP doesn't certify applications or companies against the Top 10. Customers and auditors may ask how you handle each risk, and for a formal, testable baseline OWASP recommends its ASVS.
Does the OWASP Top 10 apply to Odoo and other ERP systems?
Yes. Odoo is a web application, and custom modules can introduce the same risks as any other code, especially access control mistakes and outdated components. Odoo publishes security fixes for its supported versions, so most problems come from customizations, missed updates and server settings.
Is a vulnerability scanner enough to cover the Top 10?
A scanner helps with outdated components, settings and some injection flaws. It can't judge access rules or business logic, which is where many serious problems sit, so you also need a manual review.
How often is the OWASP Top 10 updated?
Every few years, most recently every three to four. Editions came out in 2003, 2004, 2007, 2010, 2013, 2017, 2021 and 2025.
Find out where your app stands
If your business depends on a web app, a portal or an app built with AI, it's far cheaper to find these gaps before an attacker does. Our AI code assessment checks any application for security, best practices, maintainability and readiness for production, and ends with a written report with proof for each finding and a clear order of fixes. We sign an NDA before we see your code, and assessments start from $1,000. To talk it through, book a free 30-minute call.