Contents
According to the OWASP Top 10 2025, the most widespread flaws are broken access control, security misconfiguration and software supply chain failures. In a business tool, that means customer data visible to other users, exposed keys or outdated libraries. An express audit at $660 (€589)excl. VAT can identify them.
Most flaws that hit web applications are not sophisticated. They are oversights: a missing permission check, a key left in the code, a library that was never updated. They are all the more common when the app was built quickly, without review, or generated by an AI tool. Here are the most widespread ones according to OWASP, what they look like in a business tool, and how to fix them.
The reference: the OWASP Top 10
OWASP (Open Worldwide Application Security Project) is a nonprofit foundation that publishes the Top 10 web application security risks. The 2025 edition, checked October 27, 2026, ranks these ten categories:
- A01 Broken Access Control
- A02 Security Misconfiguration
- A03 Software Supply Chain Failures
- A04 Cryptographic Failures
- A05 Injection
- A06 Insecure Design
- A07 Authentication Failures
- A08 Software or Data Integrity Failures
- A09 Security Logging and Alerting Failures
- A10 Mishandling of Exceptional Conditions
According to the introduction, eight categories come from testing data covering more than 2.8 million applications, and two from a survey of security practitioners. It is the reference I use for my audits and code reviews.
What these flaws look like in a business tool
| OWASP category | Concrete example in a business tool | Consequence | Fix |
|---|---|---|---|
| A01 Access control | By changing the number in an order’s address, a customer sees another customer’s order | Data leak, reportable breach | Permissions enforced on the server and in the database, on every request |
| A02 Configuration | Invoice storage bucket publicly accessible, debug mode on in production | Exposed documents, revealed technical details | Configuration review, restrictive defaults |
| A03 Supply chain | Libraries never updated since delivery, some with known vulnerabilities | A door attackers already know about | Dependency inventory, regular updates, automatic alerts |
| A04 Cryptography and secrets | A service’s secret key (payments, database, AI) included in code sent to the browser | Full access to the service, hijacked usage bill | Keys on the server only, immediate rotation if exposed |
| A05 Injection | A search field that builds a query from the text typed in | Database read or modified | Parameterized queries, input validation |
| A07 Authentication | No limit on password attempts, no two-factor authentication for admins | Accounts guessed or reused after a leak elsewhere | Rate limiting on attempts, two-factor authentication |
| A09 Logging | No record of sign-ins or data exports | No way to know what leaked after an incident | A log of sensitive actions, retained and searchable |
| A10 Exceptional conditions | An error message that displays the query and database structure | Valuable help for an attacker | Generic messages on screen, details in the logs |
These examples are typical scenarios, not client cases. Access control is covered in detail in managing role-based access, and authentication in two-factor authentication and account security.
Apps built in a hurry
AI and no-code tools can produce a working app in a few days. The risk is that it works for an honest user without standing up to a curious one. Two points deserve particular attention.
Permissions checked only in the browser. If the interface hides another customer’s data but the server still sends it, anyone can retrieve it with their browser’s developer tools.
Database security left off. With Supabase, which these tools use widely, the official documentation (checked October 27, 2026) states that the public key can sit in the browser provided Row Level Security is enabled on every table before going live, and that the secret key, which bypasses all those rules, must never be placed in a browser, a shipped application or source control. One forgotten table is enough to expose its data.
If your app was built this way, the AI project takeover page explains how I take it over, after an audit.
When it is not a priority
I will be straightforward: an internal tool with no personal or financial data, used by three people on a controlled network, does not need the same level of scrutiny as a client portal open to the internet. Security effort should match the data exposed and the number of users. However, as soon as an app is reachable from the internet and stores customer or employee data, the first three OWASP categories are not optional.
Where to start
- Run the simple test: with an ordinary user account, change the ID in a record’s address. If you see a record that is not yours, the priority is clear.
- Check the updates: ask your provider when the dependencies were last updated.
- Get the app audited: the technical audit comes as an express version ($660 (€589)excl. VAT, a few days) for a first assessment, or a full version ($2,300 (€1,990)excl. VAT, 5 to 7 days) with a prioritized, costed action plan. What the audit covers is detailed in web application security audit.
- Fix by order of severity, then keep it up: updates, permission reviews, checks on every new feature.
If the audit concludes that rebuilding makes more sense than fixing, the estimator gives you a first range for a business app.
Frequently asked questions
How do I know if my app has these flaws?
Some are quick to spot: sign in with a regular account and try changing the ID in a record’s address. For the rest (dependencies, configuration, keys, server-side permissions), the code and hosting need to be reviewed. That is what the audit is for, express at $660 (€589)excl. VAT or full at $2,300 (€1,990)excl. VAT.
Are apps built with AI tools more exposed?
They are not doomed to be, but they are often generated to work in a demo rather than to stand up to a malicious user. Permissions checked only in the browser and database security left off are among the first things to check.
Doesn’t a reputable host protect against these flaws?
It protects the infrastructure: servers, network, uptime. It does not fix an app that returns one customer’s data to another, or a secret key published in the code. Application security remains the responsibility of whoever builds and runs it.
Do we have to fix everything at once?
No. First fix what exposes data or allows someone to take control (permissions, keys, injection), then schedule the rest. A prioritized action plan avoids blocking your operations for weeks.