Securing web applications and the OWASP Top 10

Ransomware, phishing, identity theft, botnets, data breaches. They’re in the news every day. For software developers, this means one thing: security must be in order.

Not just at an organisational level, but also in your day-to-day work. Think of your laptop, your infrastructure and, above all, your web applications. That’s precisely where many vulnerabilities arise.

The only question is: where do you start?

A good starting point is the OWASP Top 10. This list provides insight into the most common security risks in web applications and helps you take targeted measures.

OWASP Top 10 - 2025

OWASP stands for Open Web Application Security Project. This is an open-source initiative focused on improving software security. They organise events, provide training and share knowledge and tools.

Every four years, OWASP publishes the Top 10 list of the biggest security risks in web application development. This serves as an important guide for developers. It helps to identify risks and understand what measures are required.

A new edition of the OWASP Top 10 was published at the end of 2025. A good time to reflect on the current state of affairs: what are the biggest security risks at the moment?

• The number 1 from four years ago is still at the top: Broken Access Control
• Problems in the software supply chain have increased significantly
• This is reflected, among other things, in the new number 3: Software Supply Chain Failures

Let’s look at the different categories in the OWASP Top 10 of 2025.

1. Broken Access Control

Virtually every web application includes some form of access control. Users are granted permissions to perform certain actions or view data. When a user gains access to information or functionality without authorisation, this is referred to as broken access control.

This category rose from 5th place in 2017 to 1st place in 2021 and remains at the top in 2025. This means that little progress has been made in this area. In fact, in practice, it appears that virtually all tested applications contain some form of this problem.

It is a broad category. Access control can be vulnerable in various ways, for example:

• Modifying URLs to gain access to other data
• Manipulating permissions via tokens or client-side objects
• Insufficiently secured APIs
• Errors in the CORS configuration

In 2025, Server-Side Request Forgery (SSRF) also falls under this category. This involves exploiting a server to execute unwanted requests, for example to internal systems.

Possible solutions and tips:

• Secure data by default, unless it is explicitly public
• Use a single centralised and reusable authorisation system
• Log access and flag anomalous behaviour
• Limit the number of requests, for example during login attempts
• Segment the network

2. Security Misconfiguration

This category has risen to second place. It refers to incorrect or missing configurations, not to errors in the program code. Incorrect settings in frameworks, servers or infrastructure can lead to security vulnerabilities.

Examples:

• Unused features or services that are still active
• Default accounts (often with default passwords) that have not been removed
• Error messages containing too many technical details, such as stack traces or code snippets

Possible solutions and tips:

• Disable unused components
• Ensure consistent environments (test, acceptance, production)
• Use Infrastructure as Code
• Do not display technical details to end users

3. Software Supply Chain Failures

Software development relies heavily on external frameworks and libraries. This speeds up development and avoids the need to rebuild complex functionality from scratch.

These components are regularly updated, both functionally and in terms of security. Problems arise when updates are not applied. Known vulnerabilities then remain, making the application unnecessarily vulnerable. There is also often a lack of clear insight into the dependencies used.

Managing dependencies is complex. You need to have a clear understanding of:

• which components and versions are being used
• what vulnerabilities exist
• what the impact of updates is (such as breaking changes)

The use of external components remains advisable. They are often maintained by large communities, meaning issues are quickly identified and resolved. However, this does require active management.

Possible solutions and tips:

• Remove unused components
• Check regularly for (security) updates
• Automate dependency checks (e.g. using Dependabot or NPM audit)
• Ensure visibility into dependencies (e.g. via a Software Bill of Materials)
• Consciously plan upgrades involving breaking changes

4. Cryptographic Failures

Data must be properly secured, both during transmission and storage. The requirements vary depending on the type of data, for example under the GDPR. In most cases, data will be sent in encrypted form (HTTPS), but encryption is also often required when storing data.

Common errors:

• Incorrect verification of certificates
• Weak or reused keys
• Outdated encryption methods

Possible solutions and tips:

• Classify data and determine appropriate security measures
• Do not store unnecessary data
• Use modern and strong encryption
• Also encrypt data at rest
• Use strong and unique keys

5. Injection

Injection remains a well-known and persistent vulnerability, despite all the frameworks and tools available. It involves situations where user input is executed as code.

Although this category has declined, it is still very common. The cause is usually the same: insufficient validation of input and a lack of proper separation between data and execution.

Well-known examples include SQL Injection, Cross-Site Scripting (XSS) and OS Command Injection. The impact can be significant, such as unauthorised access to data or the takeover of systems.

Possible solutions and tips:

• Validate and sanitise input on the server
• Use parameterised queries
• Ensure separation between data and code

6. Insecure design

This category focuses on the design process. Security must be taken into account from the outset, not just during implementation. An insecure design gives rise to risks that are difficult to remedy later on.

In 2021, this was a high-ranking new entry in the OWASP Top 10. Since then, the issue has dropped slightly in the rankings, which shows that organisations are taking steps to address it, for example by applying threat modelling more frequently and working according to a secure development lifecycle.

This category is less about technology and more about process. In practice, the focus is often on functionality and infrastructure, whilst security is only considered later. It is precisely during the design phase that the most important decisions are made.

That is why the security approach must be clear before any code is written.

Possible solutions and tips:

• Start with a threat modelling workshop
• Involve stakeholders and identify risks and impact
• Include security in backlog items
• Work according to a secure development lifecycle

7. Authentication Failures

This refers to issues with verifying the user’s identity.
Examples include weak passwords, unlimited login attempts, or the absence of multi-factor authentication. If authentication is not properly managed, it provides a direct entry point for attackers.

This category has changed little in substance compared to 2021, but remains an important area of focus.

Possible solutions and tips:

• Use multi-factor authentication
• Set password requirements
• Introduce a delay following failed login attempts
• Ensure that test accounts do not end up in production

8. Software and data integrity failures

This category is relatively new (since 2021) and focuses on trust in data and processes.

Examples include the use of external sources without verification, insecure CI/CD pipelines, or blindly relying on client data.

This category will remain relevant in 2025, partly due to the growing complexity of development and deployment processes.

Possible solutions and tips:

• Use components with digital signatures
• Work with reliable suppliers
• Secure CI/CD pipelines
• Enforce code reviews (four-eyes principle)
• Check data integrity

9. Security Logging and Alerting Failures

This topic concerns the logging and monitoring of events. In addition to error messages, it is essential to log authentication details as well. In the event of an incident, you want to know who did what and when.

Logging alone is not enough. Logs must be actively monitored, preferably automatically. This allows you to identify unusual patterns and send timely alerts to the right people.

Furthermore, logging is often mandatory under legislation and regulations such as the GDPR. Logs must therefore be stored securely and carefully.

Examples of security issues include:

• No logging of (failed and successful) logins
• Missing GDPR-mandated logging, such as changes to personal data
• Insecure storage of logs or unnecessary storage of personal data
• No alerts for suspicious events

Possible solutions and tips:

• Log both failed and successful logins
• Set up monitoring and alerts, or use tools that support this
• Log in accordance with laws and regulations:
  • Limit the use of personal data in logs
  • Restrict access to sensitive logs via clear protocols

10. Mishandling of Exceptional Conditions

This is a new category for 2025. It concerns the poor handling of errors and exceptions.

When exceptions are not handled properly, systems can end up in unpredictable states. This can lead to crashes, data breaches, Denial of Service (DoS) attacks or even the circumvention of security measures.

With the growth of complex systems and high-load scenarios, this is a logical addition to the list.

Possible solutions and tips:

• Validate all input
• Catch exceptions and handle them at a detailed level (i.e. do not rely on high-level error handling)
• Do not return error details from the server
• Limit the number of requests

Further considerations

The OWASP Top 10 is therefore essential knowledge for every developer. But of course, it shouldn’t stop there.

• Keep each other on your toes and make sure you follow the recommendations of the OWASP Top 10 closely.
• Work according to Security-by-Design and Privacy-by-Design.
• Start projects with a threat modelling workshop and repeat this periodically, as new code and new threats are constantly emerging.
• Hiring specialist penetration testing firms is also highly recommended.

Other Top 10 lists

In addition to this well-known “general” OWASP Top 10, there are also more specialised Top 10 lists. Take a look, for example, at:

• OWASP Top 10 for Large Language Model Applications
• OWASP API Security Top 10

Would you like more information about web application security?

The OWASP Top 10 is a valuable resource, but it remains essential to involve professional software developers and/or security specialists in the development and maintenance of software solutions.

Would you like a better understanding of your software situation, or do you have any questions? Please get in touch with us or take a look at our security training courses.