How QA Helps Build a Secure Product, Even Without Being a Security Engineer

One of the biggest misconceptions about Quality Assurance as a whole is that QA engineers rely only on verifying whether the product meets the requirements, completely neglecting the security component of the product. This statement is not true. We don’t really need to go that far to deny it, since verifying the security of a web application or any other product should be a part of the requirements document that any QA engineer examines at the beginning of the project.

Even respectable organizations such as ISTQB, which specializes in certifications in software testing and Quality Assurance, have a separate module for security testing of a web application, which just confirms the statement.

The problem, however, often is not that QA ignores security, but that the requirements miss it. And when nobody has written the security part down, it can look from the outside like QA does not care about it, while in reality, nobody ever asked them to check it. So it is crucial for every project to include this information in the documentation and help QA engineers to focus on the correct security aspects and build a secure product.

But isn’t that the security engineer’s job?

Another misconception is that QA engineers do not need to focus on the security part of the work, because there are security engineers, whose direct job it is to keep the product or infrastructure secure during and after the development lifecycle has been completed. Yes, security engineers do exist and their job is to put constant pressure on the product by testing it for potential vulnerabilities and breaches, but that does not mean that QA engineers should not touch security at all.

Security checks happen on a schedule, testing happens every day

In the majority of cases, especially for big projects, the development process is constant, and the customer and their users can use the product while it’s actively being developed and updated. Security checks most likely happen on some specific occasion or schedule. Due to the complexity of the work and how much time it consumes, most in-depth security checks happen once a quarter, once every six months, or once a year.

But a QA engineer tests the product on a daily basis. If they constantly neglect security and check only linearly, without doing cross-role checks, an authorization bypass can stay open for a whole quarter, which would be disastrous in terms of financial and reputational losses. So, it is the job of QA engineers to include security checks on a general level in their day-to-day work, in test cases or checklists, so that the most common vulnerabilities are covered.

Basic security checks a QA engineer can do

Recommendations on the basic security checks that a QA engineer can do include:

·       Run some of the crucial happy-path tests using a different role, to prevent authorization bypass issues, where a user can get access to data they are not supposed to.

·       Try to break the logic of the product, not only its input fields. A negative amount, a refund that is bigger than the original payment, a discount that can be used twice, or a step of the process that can be skipped are all logical issues that no automated scanner will find for you, because only the team knows how the product is supposed to behave.

·       Do not ignore the API requests, as they can show you what the UI does not. You need to verify whether rules are enforced on the server, not only drawn on the screen that users access.

·       Think about the errors that an application gives to the world, as they can contain information that might make your product vulnerable. If a login form answers “User not found” on one login attempt, but “Incorrect password” on the other, it gives a malicious hacker information about which addresses are actually registered. Sometimes raw SQL errors can be missed and left visible to users, which can lead to database leakage. So, you need to make sure that errors do not give more than they should.

·       Check what actually happens when a user logs out. Sometimes the session is cleared only in the browser, while the token still works on the server side, which means that the session is not really closed and can still be used by someone else.

·       Pay attention to what the application leaves on the client side. Tokens or personal data can stay in local storage, in the URL, or in the browser history, and everything that stays there can be read by anyone who gets access to the machine.

·       Always ask questions like “who can do this?” and “what should happen if someone who isn’t allowed to do this tries?”. If it’s not documented properly in the requirements, you are welcome to ask clarifying questions, so that there is no gray area anywhere, especially in terms of security.

Where QA stops and security engineering starts

But let’s not make a mistake about it. QA engineers cannot and will not replace security engineers, but they can complement each other’s work. If a QA person does a day-to-day check of the basic security items we covered in this article, they can ensure that little to no security issues reach production, and that makes the life of a security engineer easier. The security engineer can then focus their attention on more complex areas of security, which QA engineers do not have deep knowledge about. And, let’s be honest, they should not, since it’s not their job to care about complex security questions.

If everyone does their part correctly, the product that you are building will be secure and resistant to a lot of vulnerabilities, providing customers with continuous business flow and no financial or reputational losses.

At Swan Software Solutions, quality and security are treated as one conversation rather than two. If you need quality assurance or other technology services, schedule a free assessment to find out how Swan Software Solutions can help.