Audit of a Ready-Made Web Application: Code, Security, and Infrastructure Review

Acquiring a ready-made web application or planning a major overhaul is often seen as a quick way to gain a competitive edge. However, the real picture can be drastically different from the seller's presentation or the internal technical specification. Hidden vulnerabilities, architectural miscalculations, and code "crutches" can turn a profitable deal into an endless repair job. A technical audit before purchase or modification is not a formality, but a tool for making informed decisions that allows you to assess the true state of the asset. In this article, we will sequentially examine three key areas of review: code base, security, and infrastructure, drawing on the expertise of the ESK Solutions team in web application development.

Why a Technical Audit is a Mandatory Step Before Modification or Purchase

An outwardly functional product can hide accumulated technical debt, inefficient resource usage, or a deliberately non-extensible architecture. Without in-depth analysis, these issues surface at the worst possible time: when attempting to scale, during peak loads, or after handing the application over to a new team. An audit objectively answers questions that cannot be determined from a demo version:

• Correspondence of claimed functionality to actual code. It verifies that the business logic is implemented correctly, without hidden stubs or workarounds.
• Quality of architectural decisions. Evaluates the choice of frameworks, patterns, and methods of integration with external services.
• Presence and completeness of the test base. The absence of automated tests greatly increases the cost of any modifications and the risk of regressions.
• Level of vendor lock-in. How critically the application is tied to a specific developer or proprietary platform.

The result of an audit is not just a report, but a foundation for negotiating the deal price or refining the budget for post-purchase development. For example, the identified need to rewrite 30% of modules (numbers are given as an example) can reduce the asset's value by tens of percent.

Code Base Analysis: What Auditors Examine

A deep review of the source code begins with assessing its readability and maintainability. We check compliance with coding style, use of static analysis, and presence of documentation. But the main goal is to understand how quickly a new development team can get up to speed with the project and start adding value. Without this, even simple tasks can drag on for weeks.

Key aspects of code review:

• Duplication and reuse. Excessive copy-paste makes changes harder and increases the chance of errors.
• Dependencies and libraries. Assesses version freshness, known vulnerabilities, and license compliance.
• Error handling and logging. Without clear logs, diagnosing incidents in production becomes guesswork.
• Complexity and cohesion of modules. High cyclomatic complexity is usually directly correlated with the number of defects.

Practice shows that legacy web applications, especially those developed without experienced architects, often suffer from a monolithic structure. As a result, modifying one function can unexpectedly affect dozens of unrelated entities. At ESK Solutions, we help clients not only identify such issues but also plan phased refactoring—our expertise in custom web development allows us to provide a realistic assessment of effort.

Security: From Frontend to Backend

Even if the application appears to work stably, security issues can devalue the entire investment. A security review should cover both the client side and server components, as well as API integration points. The main attack vectors examined during an audit:

• Code injection (SQL injection, XSS, Command Injection). Checks for input validation and parameterized queries.
• Authentication and session management. Token storage, password policy, brute-force protection.
• Access control. Checks whether a low-privilege user can access other users' data or administrative functions.

When analyzing SaaS solutions, it is important to additionally assess tenant data isolation and resilience to attacks at the multi-tenant architecture level. This is especially relevant if you plan to develop the product in the B2B segment — our specialists in SaaS application development know which security incidents are most common in such systems. The final security report should contain not only a list of found vulnerabilities with CVSS scores but also practical recommendations for fixing them in order of priority.

Infrastructure: How to Assess Server Environment and Scalability

Code and interface are just the tip of the iceberg. Without an infrastructure audit, it is impossible to understand the true cost of application ownership and its ability to grow. The infrastructure check includes:

• Deployment architecture. Whether containers (Docker), orchestration (Kubernetes) are used, and what the load balancing scheme is.
• Cloud configuration. If the application runs on AWS, Azure, or Yandex.Cloud, we audit network settings, security groups, and autoscaling policies. We check whether you are overpaying for excessive resources and whether there are bottlenecks as traffic grows.
• CI/CD and DevOps practices. Whether build and deployment are automated, whether isolated development/testing environments exist, and how the rollback process is set up.
• Monitoring and alerting. The presence of a metric and log collection system (Prometheus, ELK stack), configured dashboards, and notifications for critical events.

During an audit, it is not uncommon to find that an existing system uses outdated or suboptimal cloud environments, and planned improvements will require migration. In such cases, it is justified to bring in a team with experience in cloud development and support to design a target architecture that will withstand the planned load and be cost-effective. For corporate clients considering the purchase of a CRM platform or an internal portal, such an audit is critically important — any downtime or data leaks are unacceptable, and we are well familiar with such systems as we specialize in CRM development and integration.

Frequently Asked Questions

How long does a technical audit of an application take?

The duration depends on the size of the codebase, the number of integrations, and the complexity of the infrastructure. A standard audit of an average web application typically takes 5 to 15 business days. In high-urgency cases, we can provide preliminary findings within 3–4 days.

What initial data is needed to start?

At a minimum, access to the source code repository and documentation (if available). For a full infrastructure and security check, we will also need accounts for cloud panels and the test environment. We guarantee confidentiality and are ready to work under an NDA.

Can an audit be conducted if the current development team is unavailable?

Yes, this is a common situation, especially in M&A deals. We work with the provided artifacts and available access. The absence of the previous team complicates understanding of some architectural decisions, but the experience of our engineers allows us to reconstruct the picture from the code and configurations in 95% of cases.

What will be in the final report?

You will receive a structured document with an executive summary for management and a detailed technical section. It includes: a map of identified risks (code, security, infrastructure), prioritization of issues according to the "important/urgent" principle, an approximate estimate of the effort required for fixes, and recommendations for the target architecture. Such reports have repeatedly helped our clients reduce rework costs and avoid unsuccessful acquisitions.