Security tests: what are they and why are they worth the trouble?

System and app security represents a key aspect of any digital environment today. Security issues or incidents may lead to dangerous data leaks, privacy breaches, lower customer trust and significant financial losses. This is why it is so important to always design, develop and maintain your software in accordance with the very best practices. You need to perform regular IT security testing and monitor your IT infrastructure, keeping in mind the importance of adequate vulnerability assessment. After all, you have an obvious goal: the security of every system user.

Security tests what are they and why are they worth the trouble

What are security tests about?

A security test is a controlled process aimed at detecting the greatest number of possible errors that potential attackers could capitalise on to gain unauthorised access to your data. Simply put, security testers put themselves in the shoes of cyberattackers; guided by ethical standards, they perform what is known as penetration tests, whose aim is to break through your system safeguards. At the end of the process, you get a detailed report that includes a list of detected security issues, along with proposed solutions and security improvements.  

Security testing is designed to boost overall app or system security and reduce the risk of attacks. Importantly, however, they do not guarantee 100% security; what they do is reduce the potential area of attack. After all, testers often have only limited time to identify security gaps, while potential hackers work under no such time constraints. 

In addition, security testing should be repeated at regular intervals as your app is continues to be upgraded. Remember: each change can introduce a potential security error and “opening the door” to potential threats. 

Penetration tests. Manual vs automated tools

Security testing can be supported by automated security tools. They can be divided into two basic types:

  • Static tests (SAST) — use the “whitebox” approach, which requires access to the source code/configuration files, but not to a “live” app. Automated scans are fast, but generate a large number of false positives, which need to be double-checked manually. Automated security tools may be integrated into the CI/CD process, even when coding in IDE environments. Examples include SonarQube, SonarLint.
  • Dynamic tests (DAST) — use the “blackbox approach”, which requires access to a live app, but not to the source code or configuration files. Dynamic tests rely on the app’s actual infrastructure and enable a wider range of testing. They generate fewer false positives. One example is OWASP ZAP.

Even though automated security testing tools are highly useful, they are not free from limitations. They are based on rules that need to be updated as a function of technological advancement, e.g., with the advent of new frameworks or libraries. Automated security tools are also ignorant of the app’s logic or purpose, so they can’t detect logical errors, which may cause catastrophic security flaws.

For this reason, security testing should not rely solely on automated security testing tools, these tools should support manual penetration testing.

Top app security problems

Security vulnerabilities. The risk of losing confidential information

One of the most frequent vulnerabilities is “Broken Access Control”. Simply put, it involves an incorrect verification of resource/user access permissions to functionality X or resource Y.

As a consequence, an attacker may, e.g., acquire incorrect authorisations and access other users’ data. For instance, on the customer (frontend) side, admin forms should never be displayed to users who are not admins. However, on the server (backend) side, there are often no verification tools to determine whether a user who triggers an action is indeed an admin.

This error – when, due to unauthorised access, users with lower permissions can perform actions reserved for users of another type (such as admins) – is technically known as “vertical privilege escalation”.

On the other hand, if a given use type does have access, e.g., to private file uploads, but no methods exist to verify whether the user really uses their own file, this is referred to as “horizontal privilege escalation”.

It is no coincidence that “Broken Access Control” made it to the top of the OWASP Top Ten 2021 list of potential vulnerabilities.

It is a class of vulnerabilities that cannot be detected with manual tools; automated tools don’t understand the context of the app and lack relevant business knowledge. They cannot determine whether functionality X should be accessible to everyone or just the HR team. Or if file Y should be available to a given user.

OWASP Top ten list of potential vulnerabilities for security testing. 2017 and 2021 comparision

Inappropriate separation of environments

Another frequent problem is that testing and development environments are often not properly separated from production environments.

While a lot of care is often taken to ensure the security of the latter, many people believe that testing environments do not require equally strict safeguards (since they do not normally store sensitive data).

This line of thinking, however, is wrong. The same secrets, e.g., the same keys, are often used to verify JWT signatures both in testing and production environments. If this is the case, anyone who gets access to a privileged account in the testing environment can acquire the same permissions in the production environment.

In practice, this means that the security of the production environment is the same as that of the testing environment.


When it comes to security, it is not enough to focus on the app layer. The whole system is only as secure as its weakest link, so don’t forget about your infrastructure either. Has your webserver (Apache, nginx) been upgraded to the current version without any known vulnerabilities? Are you sure there are no configuration errors? For example: nginx alias traversal.

Also: are you sure you don’t have too many frontend services? For instance, JDWP (Java Debug Wire Protocol) may lead to Unauthenticated Remote Code Execution, tantamount to a complete system takeover.

You should also ensure configuration security if you’re using services offered by cloud providers (e.g., AWS, Azure, GCP). While a dangerous AWS S3 bucket configuration is now rare, there are many other services where configuration errors may cause serious security flaws. These include, e.g., AWS API Gateway and AWS Cognito.

IT security testing: why is it worth the trouble?

Why are security tests worth the trouble? As we have shown, there are many threats out there, and after all prevention is better than cure: it is cheaper to prevent an attack than handle its aftermath – just as it is cheaper to test apps as you develop them than hold back until the end of the project.

Incident response can put a huge strain on your budget. You might need to perform a post-breach assessment, cancel secrets (API keys, access tokens), enforce user password changes and notify appropriate authorities of the data breach. What’s worse, your customers’ data may be leaked, resulting in lower customer trust.

Another good reason to perform security tests is that they are required by law. If you want to be sure that a partner in charge of developing, maintaining or upgrading your software performs regular security testing, ask to see their ISO/IEC 27001 certificate, for instance.

Do you want to prevent threats and need help with security testing?