Claranet’s top 10 web application vulnerabilities found in 2024

Web applications are a common target during cyberattacks. Threat actors choose them because:

1. They are easily discoverable online
2. They often contain vulnerabilities from the open-source code libraries they use
3. Developers are under pressure to release code faster than ever before, and therefore miss security vulnerabilities (or don’t know how to spot them)
4. Changes in code and new attack techniques mean that new vulnerabilities can go undiscovered for weeks or months if organisations only conduct penetration tests once a year

For this reason, web applications receive special attention from threat actors and deserve the same level of attention from developers and security teams. Claranet recently conducted research from the results of our penetration tests, comparing the most common web application vulnerabilities found in a select sample size of 500 web application pen tests in 2024. Additionally, we spoke to our team of expert pentesters to find out the common trends and security fixes you can implement to mitigate against such threats. 

Executive Summary

While many of the top OWASP 10 findings have made it into our findings, our research discovered some variation from that list. Particularly, we found that many web applications still contain easily exploitable vulnerabilities that can be chained together to create much more powerful impacts. It is important to eradicate low-hanging fruit for attackers, especially when they may lead to compromising the confidentiality, integrity or availability of an application, or the application can be used as a stepping stone in a longer cyberattack. We hope that development teams can use these findings to improve the security of their applications. Web applications still suffer from vulnerabilities that have been around for many years. There has been a notable shift from more common exploits found such as a lack of SQL injection and command OS injection, but Cross Site Scripting (XSS) is still prevalent. One of our initial conclusions is that Claranet’s clients have been actively introducing security defences into their web application development cycle, using penetration testing and Continuous Security Testing, as well as implementing training such as Application Security for Developers and DevSecOps training.

1. XSS Reflected and Stored

Claranet was able to find 2570 instances of Cross Site Scripting (XSS) reflected and stored within the web applications we tested in 2024. It was also one of the most common vulnerabilities found in applications we have tested over the past five years. It was often linked to another finding below such as out of date JavaScript libraries. XSS can range from a medium to high-level finding depending on where in the application it was found.

What is XSS?

• Reflected XSS occurs when user input is immediately reflected back in the response from the server without proper validation or encoding. For example, if a search term is displayed on a webpage and that term contains malicious code, it can execute in the user’s browser.
• Stored XSS happens when malicious input is saved on the server (in a database, for example) and later served to other users. This means the malicious input can affect anyone who views the stored content, such as comments or user profiles.

How to defend against XSS

• Deploy Web Application Firewall (WAF)
• Sanitise and escape input: clean and validate user input, and escape special characters before rendering in the browser.
• Use Content Security Policy (CSP): define strict rules to control the sources of scripts and content.
• Use HTTPOnly and secure cookies: Protect cookies from JavaScript access and enforce HTTPS transmission.
• Validate input: Perform both client-side and server-side validation.
• Avoid inline JavaScript: Externalise scripts and avoid directly embedding user data in HTML or JavaScript.
• Use modern frameworks: Rely on frameworks like React, Angular, or Vue.js that inherently escape input.
• Use safe APIs: Prefer safer methods like textContent over innerHTML to prevent HTML injection.
• Audit open source and third-party code libraries: regularly check open source and third-party libraries for security risks using vulnerability scanners.
• Deploy Web Application Firewall (WAF): Add a layer of protection against XSS attacks.
• Perform security testing: Use automated tools and manual reviews to identify vulnerabilities.
• Context-specific escaping: Escape data appropriately based on where it will be inserted (HTML, JS, URLs).
• Limit risky features: Disable or limit features like eval() and innerHTML to reduce attack surface.

2. Out of date JavaScript libraries

We found 1032 instances of out of date JavaScript libraries in use across multiple web applications tested in the year 2024. Using out of date JavaScript can lead to XSS, Denial of Service attacks and sensitive information disclosure on the affected page.

What are out of date JavaScript Libraries?

Out of date JavaScript libraries are no longer actively maintained, updated, or supported. Using outdated libraries can lead to various issues, including security vulnerabilities, compatibility problems, and application features malfunctioning.

How to defend against out of date JavaScript Libraries

Regularly update dependencies

• Monitor for updates to libraries and frameworks. Use tools that audit for alerts on outdated or vulnerable dependencies.
• Research the maintenance status and community support of each library.
• Check recent activity on its repository or official site.

Use newer alternatives if necessary

• Adopt actively maintained frameworks (e.g., React, Angular, Vue.js).
• Use built-in solutions and native browser APIs.

Implement security practices

• Follow secure coding practices.
• Perform regular security audits of code and dependencies.

Maintain compatibility

• Test your application thoroughly after library updates, using automated vulnerability scanners, penetration testing or Continuous Security Testing.
• Use version pinning to control dependency versions.

Documentation and training

• Educate your team on the importance of updating libraries.
• Document processes for updating dependencies and handling libraries.

Plan for migration

• Develop a migration strategy to transition from outdated libraries to modern alternatives.

3. Clickjacking

We found 1226 instances of clickjacking in 2024, affecting over 80% of the ~500 web applications sampled for this research. Clickjacking is often reported as a low risk issue, however depending on the context of the web application can have devastating effects on the overall security of that application.

What is Clickjacking

With Clickjacking, attackers trick users into clicking on something different from what the user perceives, essentially "hijacking" their clicks. This is typically done by embedding a transparent or opaque layer over a legitimate webpage, causing the user to unknowingly interact with hidden elements, such as buttons or links that execute malicious actions.

How to defend against Clickjacking

• Frame-busting: Websites can implement code that prevents their content from being loaded in iframes, which attackers often use to overlay malicious content.
• X-Frame-Options Header: Modern browsers support the X-Frame-Options HTTP header, which websites can use to prevent their pages from being loaded into iframes by attackers.
• Content Security Policy (CSP): CSP frame-ancestors directive can help prevent clickjacking by restricting which domains are allowed to embed the site in an iframe.

4. Server Header Disclosure

Often the infrastructure that the web application is hosted on is also tested as part of a penetration test. We found that information on software versions used by the application is often found within HTTP response headers. This information can be used by attackers to better understand the software that is used by the application and then research any known vulnerabilities in that software. Such information is also harvested by tools such as Shodan and made publicly available, which allow for attackers to passively identify potential targets for attack.in that software. Such information is also harvested by tools such as Shodan and made publicly available, which allow for attackers to passively identify potential targets for attack. We found 4631 response header disclosures across the sample size of ~500 web apps we tested in 2024.

What is Server Header Disclosure?

Server Header Disclosure refers to the exposure of information about the web server and its software in the HTTP response headers. When a server responds to a client (usually a browser), it sends a variety of HTTP headers that describe the response. If the server is misconfigured or not properly secured, it may include sensitive details in these headers, such as the name, version, or type of server software (e.g., Apache, Nginx, IIS), the operating system, and even details about installed modules or software versions.

How to Defend Against Server Header Disclosure

• Suppress server information: configure the web server to suppress or remove the server header entirely, or at least limit the amount of information shared.
• Content Security Policy (CSP): While CSP doesn’t directly address server header disclosure, ensuring the right CSP rules can minimise other risks associated with the exposure of server details.
• Use reverse proxies or load balancers: these can act as intermediaries between the client and the server, potentially hiding specific server details from being exposed.

5. Missing cookie attributes

On many authenticated web application penetration tests, cookies used for authentication were often missing one or more secure cookie attributes. We found 769 missing cookie attributes across ~500 web applications tested in 2024.

What are missing cookie attributes?

Missing cookie attributes refers to a security issue where cookies, particularly where they are used to store session data or other sensitive information are not configured with important security attributes. These attributes help protect the cookie from being stolen or manipulated, reducing the risk of attacks such as Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF).

How to defend against missing cookie attributes

• Always set the Secure, HttpOnly, and SameSite attributes appropriately, especially for cookies that store sensitive data.
• Use Secure for all cookies if your site uses HTTPS.
• Set HttpOnly to prevent client-side access to sensitive cookies.
• Use the SameSite attribute to limit when cookies are sent in cross-origin requests, helping to mitigate CSRF attacks.

6. TLS1.0 & 1.1 in use

Over the past five years, we have found that most web applications still use older TLS1.0 & TLS1.1 (Transport Layer Security) protocols. We found 3703 instances of TSL1.0 and 4062 instances of TLS 1.1 across ~500 web applications in our 2024 sample selection.

What is TLS1.0 & 1.1?

TLS 1.0 and TLS 1.1 are early versions of the Transport Layer Security protocol designed to secure communication over a computer network, particularly in web traffic (e.g., HTTPS connections). However, both versions are now considered outdated and insecure due to various vulnerabilities that have been discovered over time.

How to defend against TLS1.0 & 1.1

• Disable TLS 1.0 and TLS 1.1 on your web servers (e.g., Apache, Nginx, IIS) and enable only TLS 1.2 and TLS 1.3.
• Enable strong cipher suites, and disable weak ones (e.g., RC4, DES, 3DES, SHA-1).
• Use Perfect Forward Secrecy (PFS) by prioritizing cipher suites like ECDHE or DHE.
• Upgrade to TLS 1.3, which offers better security and performance.
• Manage certificates securely, using trusted CAs and strong keys (2048-bit RSA or higher).
• Test your server’s TLS configuration regularly using tools like Qualys SSL Labs, Nmap, or Testssl.sh.
• Monitor and patch your systems and web applications frequently to keep them up to date.
• Ensure client compatibility by upgrading applications and integrations to support TLS 1.2 and 1.3.
• Implement HSTS (HTTP Strict Transport Security) to force HTTPS connections.
• Consider using a Web Application Firewall (WAF) for added protection against attacks.

7. No account lockout

While no account lockout was commonly identified on a large number of web applications that we have tested over the past five years, during 2024 we found only 35 instances of no account lockout across ~500 web applications. For modern web applications, this is an essential security control, which is becoming increasingly common.

What is no account lockout?

No account lockout happens when there is no limit on the password login attempts set by the application. To defend against brute force and credential stuffing attacks, many web applications have a lockout policy where, after a defined number of unsuccessful login attempts (usually due to wrong passwords), the user’s account is temporarily or permanently locked to prevent further access.

How to defend against no account lockout policy

• Throttle / limit login attempts: Limit the number of login attempts per user or IP within a certain period.
• Progressive delays: increase wait times between successive failed login attempts.
• Captcha or Multi-Factor Authentication (MFA): CAPTCHA and MFA should be implemented as standard for initial logins and required again after multiple failed login attempts.
• IP address blocking and monitoring: block or monitor suspicious IPs with repeated failed logins.
• Account activity notifications: notify users of failed login attempts or unusual activity.
• Strong password policies: Enforce complex passwords and mandate regular updates.
• Token-based authentication: use OAuth or JWT for authentication instead of passwords alone.
• Account lockout recovery (soft lockout): Temporarily lock accounts with a recovery option.
• Honeypots and deception: detect and block attackers by using honeypot accounts.
• Device recognition: identify trusted devices and require additional verification for unknown ones.

8. Missing HTTP security headers

We found missing HTTP security headers on over half the web application assessments done during 2024. By not having the correct HTTP security headers set within HTTP POST & GET requests, web applications are vulnerable to the following: 

9. Verbose error messages within web applications

We found verbose error messages in around 60% of the ~500 web applications we sampled for this research. 

What are verbose error messages?

Verbose error messages provide detailed information about the errors or issues encountered by a program or system. Unlike standard error messages, which might be brief and vague, verbose error messages aim to give a more in-depth explanation to help developers or users diagnose and resolve the problem. Verbose error messages are often helpful to attackers as they often provide an insight to the tech stack of the application and potentially further information as to what the application is doing.

How to defend against verbose error messages

It is recommended to ensure error messages are generic to prevent an attacker from learning more about the application that they are targeting.

• Limit information in production environments: disable verbose error messages in production and only provide generic messages to users.
• Log detailed errors privately: log verbose errors securely for internal use, without exposing details to users.
• Sanitise inputs: validate and sanitise user inputs to prevent attackers from triggering detailed error responses.
• Custom error pages: use custom error pages that don’t reveal system details and log errors internally.
• Role-Based Access Control (RBAC): Restrict access to detailed error messages, showing them only to authorised users (e.g., admins).
• Tune verbosity levels: Set appropriate error verbosity levels in production environments and suppress stack traces for end users.
• Regular security audits: conduct audits and penetration tests to ensure verbose messages aren’t inadvertently exposed.
• Use error tracking tools: implement tools to monitor and log errors securely.
• Encrypt sensitive data in logs: encrypt or mask sensitive information in logs to prevent unauthorised access.
• Keep application stack secure: Regularly update software and review configurations to ensure verbosity is controlled.

10. Malicious file upload

We found 574 instances of web applications vulnerable to malicious file upload across the ~500 web applications we tested in 2024. 

What is malicious file upload?

Malicious file upload is a type of security vulnerability where attackers exploit the file upload functionality of a web application to upload malicious files that can compromise the system or execute unauthorised actions. These malicious files can contain scripts, executables, or code that, when uploaded and executed, enable attackers to damage the functionality of web applications, or perform unauthorised actions as part of a broader, staged cyberattack.

How to defend against malicious file upload

• Restrict file types: only allow specific file types and validate file content on the server side.
• File name sanitisation: rename uploaded files and remove harmful characters from file names.
• File size limitations: set limits on the maximum file size for uploads.
• Store files outside web root: store uploaded files outside public directories to prevent execution.
• Use file scanning: integrate antivirus tools to scan files for malware.
• Disable script execution: ensure uploaded files cannot be executed as scripts by disabling execution permissions.
• Content-Type and MIME-Type validation: check file MIME types to match expected file types.
• Use secure file upload libraries: utilise secure file upload libraries with built-in protections.
• Limit upload locations: restrict file uploads to specific directories and monitor them.
• Implement strong access controls: limit file upload permissions to authenticated and authorized users.
• Use a Content Delivery Network (CDN): serve uploaded files through a CDN to separate them from the main application.
• Monitor and log uploads: log and monitor all file uploads for suspicious activity.
• Regularly update software and libraries: keep all software and file handling libraries up to date with security patches.

Future of web application testing and new issues on the horizon

While new attack techniques emerge frequently, vulnerabilities in web applications often stay the same for years at a time. For example, consider how often the OWASP Top 10 needs to be updated. If vulnerabilities and attack techniques changed at a faster rate, this list would need to be updated more frequently. New AI chat bots allow for end users to have a "real" conversation and get data back from them. Claranet has seen an increase in the number of web applications now making use of private AI/LLM models that are used within web applications.

How does AI/LLM increase the attack surface on an application?

Recently, we have seen an increase in the number of web applications making use of private AI/LLM models that are used within web applications. Claranet has already conducted and come up with the following research on how LLMs can be attacked. The following is a short list Prompt injection attacks: manipulated user inputs can alter the behaviour of a model, leading to unintended or harmful outputs. Data leakage: the model might expose sensitive data, including Personal Identifiable Information (PII) or proprietary information, if not properly managed. Insecure API endpoints: poorly secured API endpoints can be exploited for unauthorised access, data tampering, or service disruption. Adversarial inputs: crafted inputs can mislead or confuse the model, causing it to generate incorrect or dangerous outputs. Bias and manipulation: built-in biases can be exploited, leading to discriminatory or harmful responses and potential manipulation of the system While more security research is required to uncover all possible vulnerabilities that LLMs can add to an application, developers should also be especially careful of using them for coding purposes. Recent research has shown they are vulnerable to typosquatting attacks, attempts to poison training data sets, attackers targeting AI hallucinations, and creating code repositories containing malware, are just a few examples of why we must invest more resources in securing large-language models.

Analysis of results and advice for developers

A key piece of advice for development teams is to monitor the JavaScript code they use to ensure they remain within active support and include the latest patches. Any open-source code repositories and third-party components used in application development should be checked using vulnerability scanners and tested in preproduction environments. Because developers are often under pressure to release new code quickly, teams can build efficiency gains into their DevSecOps processes by using Continuous Security Testing to uncover and fix vulnerabilities in application code as they arise and reduce the window of vulnerability their application faces. Get in touch with today to find out more information about how penetration testing and Continuous Security Testing can secure your web applications, as well as how Application Security for Developers and DevSecOps training can empower your team to implement safer application development practices.