top of page

What to do When Your Web Application or API Penetration Test Fails

Cybercrime damages a company's reputation, disrupts operations, puts your intellectual property at risk, and has other negative consequences.

One way to ensure your IT systems are resilient to cybercrime is by applying penetration testing. Penetration testing, or pentesting, simulates attacks on IT systems to uncover vulnerabilities in firewall systems, applications, and other system components. The objective of pentesting is to discover and address the underlying system's vulnerabilities before an attacker does.

In this article, you'll learn why your organization needs to perform pentesting, as well as some of the common vulnerabilities found during the pentesting process. You'll also learn how to fix common issues discovered during the pentesting process, and how you can deploy a Web Application & API Protection solution to mitigate attacks.

Why Pentest Your Application

Pentesting offers several benefits to your organization.

First and foremost is that pentesting allows you to discover and remediate vulnerabilities. Since pentesting will detect the existing weaknesses and attack vectors in your system and infrastructure, you'll be able to address these vulnerabilities before they're used against you.

It is true that there are some vulnerabilities you’ll need to act on immediately, but there are other vulnerabilities you might not need to address, since they are already mitigated by other system components.

An example could be a legacy website that uses plain HTTP. This is a clear security concern, but one way it could be mitigated is if that website is only exposed via a load balancer that serves HTTPS traffic on its behalf. Pentesting helps you to identify not just what's vulnerable, but also helps identify which attack vectors pose a direct threat, and thus where you should focus your mitigation efforts.

Pentesting also helps to ensure business continuity and that your operations do not get interrupted or become inaccessible. When pentesters identify vulnerable parts of your IT infrastructure, you gain a better understanding of the effects that vulnerabilities can have, which allows you to create business continuity plans for specific scenarios.

Pentesting is also crucial if you're seeking compliance with security certifications. Several industry certifications, such as ISO 27001 and PCI, require a specific degree of penetration testing to be in place. Absent or insufficient pentesting can result in certification rejection and loss of business opportunities.

What are Common Vulnerabilities Found During Pentesting?

OWASP is a nonprofit foundation that works to improve software security through several initiatives. One of the valuable resources from OWASP is the OWASP Top Ten, which is a periodic assessment of common high-impact vulnerabilities found in web applications. Here are some examples of common vulnerabilities that may show up in penetration testing:

  • Broken Access Controls: An access control policy specifies what users can and cannot access according to their assigned permissions. Failure to properly configure access controls can lead to unauthorized data access and modification.

  • Security Misconfigurations: Security misconfiguration encompasses a wide range of issues that can affect application security, such as unnecessary open ports, accounts that use default passwords, overly informative error messages, and lack of server security headers.

  • Injection: This is a type of vulnerability that enables an attacker to inject data into the application, which then executes malicious commands in the system. One of the common types of the injection is SQL injection using queries against the database. It mainly works on SQL interpreters that accept unsanitized input from the outside world. Other types are command injection and cross-site scripting, which involves injecting harmful scripts from a source the user thinks is a trusted source.

What are the Consequences of Pentesting Failure?

A failed penetration test comes with several consequences. One of the most common results of failed pentesting is project delays, as the application developers and network engineers will need time to analyze and fix the highlighted vulnerabilities.

As mentioned earlier, some industries, such as the payment industry and health care, require ISO 27001, SOC2, PCI, or other security certifications, which often require that the underlying systems pass a certain degree of pentesting. Failure to pass pentesting may lead to a loss of certification and loss of business opportunities. For example, a financial provider may no longer be allowed to conduct bank transactions or hold debit/card information if they lose their PCI certification status.

It's worth mentioning that the decision the business will take based on pentesting results is pragmatic. That is, the business must always balance the risk of not fixing the pentesting issues vs. the opportunity cost of increasing the time to market.

For example, suppose the issues found during the pentest are non-critical. In that case, the business may be willing to move forward with the project as it is, believing that the benefits of an earlier release are greater than the potential losses if the vulnerability is exploited.

What if Your Pentesting Fails?

A failed penetration test is bad news, and you need to take actionable steps to address the situation. Here is a suggested course of action the pentesting team can follow.

As a failed pentesting is likely to affect project timelines and budget due to the time and effort required to resolve the issues, the failure should be communicated as soon as possible to relevant stakeholders, such as executives, product owners, solutions architects, and developers.

You also need to triage the vulnerabilities discovered in the pentesting. Triage is analyzing vulnerabilities and identifying their impact and priority. This step is important, as you want to focus your time and effort on the most crucial vulnerabilities. If your pentesting was done in house, your team may have already prioritized any issues found and discussed them in their pentesting report. If the pentesting was done by a third party, you'll often need to perform triage yourself.

After you've identified the vulnerabilities and their potential impact, decisions need to be made about how to address each vulnerability. These decisions are generally made in consultation with stakeholders and security experts, and aim to balance business and security needs.

Typical decisions taken regarding a security vulnerability are fixing it, using other system components to mitigate the risk, or postponing action on low-risk vulnerabilities. Here are some examples of the questions you may ask yourself before deciding on when/what vulnerability to fix:

  • Low-risk vulnerability: Do we have to fix this vulnerability right now?

  • Medium-risk vulnerability: How long will it take to fix this vulnerability? Are there any other components that already protect against this vulnerability in some way, such as a non-SSL service protected by SSL WAF? How much time will it take to fix this?

  • High-risk vulnerability: Do we need to delay the project to resolve this? Can we delay the release of this system component without compromising the system functionality? Do we need to bring in a security expert to resolve this issue?

The steps mentioned above are usually performed iteratively rather than linearly. Moreover, it is necessary to keep all the stakeholders updated in the communication loop throughout all the steps of the process.

How to Fix Pentesting Issues

When your pentesting is completed, your testers will provide you with a report that can be used as a starting point to fix the different vulnerabilities.

In this section, you'll look at how you can resolve some of the security vulnerabilities mentioned earlier in the article.

Fixing Broken Access Controls

There are several measures you can apply to fix broken access controls. OWASP A01 Broken Access Control indicates some of these measures.

First, deny access to all non-public resources by default. This will ensure that resources are inaccessible to the users unless they are explicitly granted access. It is preferable to restrict an authorized user's access by mistake than it is to grant access to an unauthorized user.

Secondly, re-use control access mechanisms. This will make it easier for developers to apply consistent access policies across different application modules. It will make fixing bugs easier, as authorization logic only needs to be maintained in a single place.

Thirdly, rate limit APIs and controllers. This will help to minimize the harm from automated attack tools. Rate limiting specifies a maximum number of requests your API will accept from a user in a given time period, such as fifteen requests per minute. This significantly limits the usefulness of automated attacking tools by reducing their speed.

Fixing Security Misconfigurations

OWASP A05 Security Misconfiguration explains many actions to fix security misconfigurations.

One of the key things you should do to help reduce security misconfigurations is to automate your environment's setup. This will help you maintain a consistent state among different development, testing, staging, and production environments. It ensures that all environments are identical and there is no configuration drift, which may lead to security vulnerabilities.

You should strive to maintain as minimal an environment as possible. Any unnecessary software, features, frameworks, or artifacts should be removed from your infrastructure, which will minimize attack vectors.

Require your applications to send security headers to the client. HTTP security headers are headers sent from the server to the client to provide an extra layer of privacy. This helps to protect against attacks such as manipulator in the middle, cross-site scripting, cross-site request forgery, and other attacks.

Fixing Injection Attacks

OWASP A03 Injection provides suggestions on how to address the SQL injection attacks.

Use safe APIs. Avoid direct calls that rely on the SQL interpreter behind the scenes (ie do not construct SQL queries dynamically). Safe APIs use pre-built queries that prevent SQL injection. It's also important to use escape characters in dynamic queries. Most SQL injection attacks rely on being able to craft a query that prematurely closes string parameters using special characters. To help avoid this, it's best practice to escape the user inputs using the specific escape character for the SQL interpreter you use.

As for XSS, PortSwigger cites some measures to effectively address it, such as filtering input on arrival to prevent incoming JavaScript, encoding data on output to prevent interpreting it as active content, and using correct response headers.

How to Prevent Pentest Failure

The most common method to prevent attacks as well as pentesting is by use of Web Application & API protection software, also known as Web Application Firewall (WAF).

There are many solutions in the market and many considerations. Some key considerations for selecting a solutions are:

  • Security coverage for both known (e.g. OWASP-Top-10) and unknown attacks (Zero Day attacks)

  • Ability to limit inputs to APIs using Schema Validation thus reducing the attacks surface and inputs that can get to the application.

  • On-going maintenance overhead - how much time do you need to spend to manage the security solution as your application and APIs evolve?

  • Openness and Cost - you may want to consider an open-source Web Application & API security solution.


In this article, you have learned what pentesting is and how it assists organizations in discovering vulnerabilities, ensuring business continuity, and maintaining certification compliance. You've also learned about common issues that are discovered in penetration testing, as well as what you should do if your pentesting fails.


Experiment with open-appsec for Linux, Kubernetes or Kong using a free virtual lab

bottom of page