Prepare your applications, this is a security audit

This article is about application security audits, the very thing that is often thought about after something has already gone wrong. If you were at CrossConf, you remember that this is the topic of my presentation and it is quite extensive. Therefore, there will be several articles.

In this part, I will tell you a little about the types of audits, resources for self-checking, and why preparation is so important. If you are a developer who wants to make your application better and safer, then this article is for you.

What types of audits are there

There are actually three broad ones. These are Black box, Grey box, and White box.

Black box — you do not provide anything to the auditors. They just download your APK or iOS version from the app store, install it, and try to hack it. They do not have access to the code, documentation, or infrastructure.

✅ No preparation required: you just give the auditors access to the application, and they start working.

✅ Helps to assess the security of the application as real attackers do.

✅ Suitable for analyzing how vulnerabilities can affect the company's reputation and user experience.

🤐 Limited depth of verification, many problems on the server side or in the code remain unnoticed.

🤐 Identified vulnerabilities may be general and not take into account the nuances of the internal architecture.

🤐 Results depend on the professionalism of the auditors, not on your preparation efforts.

Gray box — all the same, but you also provide some test data so that the auditors can log into the application and, for example, affect the backend or something else. This allows for an audit of both the client and server sides of the application.

✅ Allows you to identify more vulnerabilities and, for example, check the data transfer between the client and the backend.

✅ Helps to understand how weaknesses in the application architecture can be exploited by attackers.

✅ Balance between effort and depth of inspection.

🤐 Preparation is required: you need to collect test data and explain to auditors how the application works.

🤐 May miss some hidden vulnerabilities — auditors still do not see the whole picture.

🤐 The result depends on how well you conveyed the key information.

White box — you fully disclose the internal workings of the application to the auditors: source code, repositories, architectural diagrams, and documentation. They conduct a deep analysis at all levels of the system.

✅ Maximum depth of inspection.

✅ Useful for improving code and infrastructure quality.

✅ Helps build trust with clients or partners because it confirms compliance with security standards.

🤐 It takes a long time: a lot of information needs to be collected and passed on to the auditors.

🤐 Risk of data leakage if auditors are not reliable enough or use reliable data transmission channels.

🤐 It can be difficult to implement if the project's documentation or infrastructure is not in order.

Three stages of the audit

First stage — it's just the beginning. You receive a message that there will be an audit soon. This is a good time to prepare. What is useful to do before the start:

1. Conduct a self-check. I will tell you about it separately below.

2. Create a test environment. Set up an environment where auditors can work without risking production. When preparing a test environment, it is very important to consider that it should fully replicate the production environment. There should be no restrictions in this environment that the real user does not have in production — this can affect the audit result.

3. Prepare and pass on the necessary data to the auditors (for Grey box and White box).

4. Make sure you have logs and metrics to track auditors' actions and see how the application responds to their requests.

5. Use checklists from OWASP or other resources to assess the current level of security.

6. Prepare the team to quickly respond to identified vulnerabilities to minimize potential damage.

The second stage is the audit itself. It is quite trivial:

• Client-side analysis. This can be an attempt to reverse-engineer the application, analyze data storage, check encryption.

• API testing. Auditors test endpoints, check data processing, authorization, and authentication.

• Artificial attacks. Auditors use various hacking techniques (SQL injections, XSS, brute force, etc.) to find vulnerabilities.

• Code review (in the case of White Box). Auditors analyze the source code for vulnerabilities, authorization errors, or data leaks.

And the third stage — you receive a document describing all your issues. You basically solve them and return to the first stage, sending everything back to the auditor. To implement changes and avoid common mistakes:

• Act quickly. Critical vulnerabilities should be fixed as soon as possible, especially if they can be exploited in production.

• Conduct retesting. After making changes, ensure that the fixes actually work and have not created new problems.

• Share knowledge. Organize an internal audit review with the team to prevent repeating mistakes.

• Update processes. If vulnerabilities are related to poor work organization (e.g., lack of code review or weak testing), change the development process.

What does self-assessment mean?

Before the audit, you can independently assess the security state of the application to find and fix obvious vulnerabilities in advance. An effective self-assessment process can be established even if there is no security specialist in the team — you just need a good checklist for verification.

Study its points and filter them according to the specifics of your project. Many points of self-assessment checklists require developers to spend additional time studying, so it is important to prepare thoroughly for a quality check.

There is a very cool site called Open Worldwide Application Security Project or OWASP - it is an international non-profit organization that deals with web application security issues. One of the main principles of OWASP is that all their materials are publicly available, and you can find them on their website. This allows anyone to improve the security of their web applications. The materials they offer include documentation, tools, videos, and forums. It is one of the most authoritative sources of knowledge on web and mobile application security.

There are three sections that you can pay attention to.

1. MASVS (Mobile Application Security Verification Standard) — these are rules that help make mobile applications secure. They are used by architects and developers to create reliable applications, and testers to check them. Essentially, it is an industry standard for application security. It is structured by security levels (1-3). This allows you to choose the appropriate set of requirements depending on your application.

2. MASWE (Mobile Application Security Weakness Enumeration) — a list of weaknesses in mobile application security. It can be used as a checklist to identify critical issues.

3. MASTG (Mobile Application Security Testing Guide) — this is a kind of ultimate guide to testing mobile applications. It describes the main vulnerabilities and methods for identifying them. You can download it as a PDF and get acquainted with it.

I recommend familiarizing yourself with these materials regardless of whether you have an audit or not. Very useful for personal development and understanding the concept of OWASP security.

There is another cool site - the Stingray company (it deals with application security), and there is a cool checklist. It can be easily used without deep security knowledge, it is structured and simple.