Technical audit of websites and applications
We review the architecture, code, security, data and release process of a live product within an agreed scope. You get an evidence-based report: a summary for the owner, findings for the engineering team, priorities and a roadmap. Your own team or any contractor can work from it. We work from Almaty with businesses across Kazakhstan.
- Code review
- Architecture
- Plan
What is a technical audit of a website or application?
A technical audit is a planned review of a product's architecture, code, security, data and release process within an agreed scope. Every finding is backed by a code reference, a configuration or a reproducible check, rated separately for severity and confidence, and comes with a recommendation. An audit is not a penetration test or a certification: it shows the real risks and the order to address them, and the report states openly what was not reviewed.
Who needs an audit
A live product before growth
New features, more load or new integrations are coming. An audit before scaling costs less than incident analysis afterwards — technical debt surfaces at the least convenient moment.
An MVP before launch or a round
The first version works, but it was built fast. You need to know what to fix before the first paying customers and what can safely wait.
A legacy system
It has run for years, but changing it is scary: an outdated stack, no tests, knowledge in specific people's heads. The audit shows what to keep evolving, what to isolate and what to replace in stages.
A change of contractor
The previous team is gone and there is no documentation. The audit rebuilds the picture for the new team: how the system works, where the risks are and where to start.
Technical check before a deal
An independent assessment of the code, infrastructure and development process before an acquisition or investment. It does not replace legal or financial due diligence.
A young team without a tech lead
An outside view of the team's decisions: what is already done well, what to fix while it is still cheap, and which practices to add first.
What problems it solves
How secure is the existing product?
The security part of the audit checks authentication and roles, access to other users' data, secrets handling and vulnerable dependencies — within the agreed scope. You get findings ranked by severity, with evidence and a fix plan. It is a review of code and configuration, not a penetration test.
Why is the website or application slow?
We look for bottlenecks: heavy database queries, missing caching, an inefficient frontend. Each comes with a recommendation and a way to verify the effect after the fix. We only draw load-related conclusions with an agreed load profile and a suitable environment.
Should the legacy system be rewritten from scratch?
Usually not. An architecture review shows which parts can keep evolving, which should be isolated and which genuinely need replacing. A phased plan is typically cheaper and safer than a full rewrite.
How do I evaluate my current contractor or team?
An independent code review gives a reasoned assessment: readability, testability, resilience to change, release process. It answers what you are paying for and which risks are piling up — with examples from the code, not impressions.
Audit types: what the scope is built from
items
- Architecture review — modules and their boundaries, dependencies, scaling bottlenecks
- Code quality — readability, duplicated logic, testability, build reproducibility
- Security review — authentication and roles, access to other users' objects, secrets, vulnerable dependencies
- Performance — database queries, caching, frontend metrics; load only with an agreed profile
- Database — schema, data integrity, migrations, backups and restore
- CI/CD — release process, environment separation, rollback
- Product readiness — logs, monitoring, error handling, operational readiness
- UX — critical user journeys and accessibility, when in scope
- Integrations — payments, 1C, CRM, external APIs: contracts and failure handling
Review levels
An audit, a security assessment and a penetration test are different jobs with different rules. We name the level up front so expectations match the result.
| Level | What it means | What it does not mean | At InterLAB |
|---|---|---|---|
| L0 Discovery | A short brief and triage | Not a code review or an audit | Free first conversation |
| L1 Express | A manual review of one specific area, limited in scope | Not full coverage, not a pentest | Express audit |
| L2 Full Review | A planned, domain-by-domain review of code and architecture, with evidence | Not a security guarantee or standards compliance | Full technical audit |
| L3 Security | Specialised security testing using methods agreed in writing | Cannot be started by a website request alone | Only after separately agreeing methods and authority |
| L4 Pentest | A separate test with rules of engagement, limited in scope and time | Not part of a regular audit | Not offered at the moment |
Reference points for review domains: OWASP ASVS 5.0.0 (web), MASVS 2.1.0 (mobile), API Security Top 10 — 2023. This is mapping against checklists, not certification: “not assessed” does not mean “passed”.
Audit boundaries
Included
- A scope agreed in writing: systems, domains, environments
- Manual code and architecture review, with tools as support
- Roles and access to other users' data, within scope
- Secrets, dependencies and environment configuration
- Database, migrations, backups
- Tests for critical journeys, CI/CD and rollback
- A two-level report: for the owner and for the team
- Priorities and a remediation roadmap
Not included without a separate agreement
- Penetration testing and exploiting vulnerabilities
- Certification or a statement of standards compliance
- A promise that no vulnerabilities remain
- Ongoing product monitoring
- Fixing the findings or all technical debt
- Load testing or active testing in production
- Legal and financial due diligence
Fixes are a separate contract with InterLAB — or work any other team can do from the report.
How to share access safely
The website form only collects a description of the task. Everything else happens after the NDA and an agreed scope.
- 01
The form is for the brief only
Do not send source code, passwords, keys or tokens through the website form or a messenger. Describe the product and what worries you — that is enough for a first estimate.
- 02
NDA and scope before access
NDA on your template or InterLAB's. Before any access we agree the scope, InterLAB's role and a contact person on your side.
- 03
A separate read-only account
Invite a separate account with read-only access to the repository, temporary where possible. Shared logins and passwords are not needed.
- 04
No real customer data
A database schema, a test environment or an anonymised copy is enough. Active testing of a live system happens only with written consent and within the agreed scope.
- 05
A report without secrets
Keys, private URLs and personal data are redacted from the evidence. The report is delivered over an agreed channel, never via a public link.
- 06
Access revocation
Once the report is delivered, you revoke the access you granted, and we confirm it together.
The exact transfer method and how long materials are kept are set in the contract.
Sample deliverable: a two-level report
At the top, a summary for the owner: what matters to the business and in what order. Below, technical findings for the team — expand any of them. The product is fictional.
Summary for the owner
- System: a fictional B2B ordering web service — Next.js, a Node.js API, PostgreSQL. Scope: API, roles, database, build and release; the mobile app and the hosting infrastructure are out of scope.
- Main risk: a user at one company can open another company's orders by changing the order number in a request (F-01). The fix is targeted — do it before onboarding new customers.
- Database backups are configured, but a restore has never been tested, so the downtime after a failure is unknown (F-03).
- No need to rewrite the architecture: module boundaries are broadly sound; the debt is concentrated in price calculation (F-04).
- Order: F-01 and F-02 before the next release, F-03 right after, F-04 and F-05 in the next phase plan.
F-01HIGHThe API returns an order by number without checking who owns itAuthorization · API1:2023
- Observed
- The GET /api/orders/:id route checks that the user is signed in, but does not compare the order's company with the user's company.
- Evidence
- src/api/orders/get.ts, lines 18–34, commit a1b2c3d (fictional). Reproduced on a test environment with two test accounts from different companies.
- Business impact
- Customers can see other companies' orders: items, prices, delivery addresses. Contractual and reputational risk.
- Recommendation
- Check object ownership on the server in every route that takes an ID, via a shared function; add an integration test “someone else's order → 404”.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P1 — before the next release · S
- Limitations
- Order and invoice routes were reviewed in full; other ID-based routes were sampled — a full inventory is recommended.
F-02HIGHThe session signing key is shared by staging and production and sits in git historySecrets and environments
- Observed
- A .env.production file was committed at some point and later deleted, but it remains in the repository history. Staging and production use the same session signing key.
- Evidence
- Git history, commit e4f5a6b (fictional); the key value is redacted in the report. The shared key was identified from the environment configuration provided by the team.
- Business impact
- Anyone who ever had repository access, including former contractors, could in theory forge a production session.
- Recommendation
- Rotate the key, separate secrets per environment, keep them in the platform's secrets manager; add secret scanning to CI.
- Confidence · reproducibility
- HIGH · INDICATED
- Priority · effort
- P1 — before the next release · S
- Limitations
- Session forgery was not attempted in production: active production testing was out of scope. The conclusion is based on configuration.
F-03MEDIUMRestoring from backup has never been testedData and recovery
- Observed
- Daily database snapshots are enabled at the provider. There is no documented restore procedure and no record of a trial restore.
- Evidence
- Backup settings (a screenshot without identifiers), a conversation with the team, no runbook in the repository.
- Business impact
- After a failure or a bad migration, nobody knows how long the downtime will be or how much data will be lost.
- Recommendation
- Run a trial restore to a separate environment, write down the steps and the actual time, and repeat on a schedule.
- Confidence · reproducibility
- MEDIUM · NOT_TESTED
- Priority · effort
- P2 · S–M
- Limitations
- No restore was performed: provider console access was outside the scope.
F-04MEDIUMPrice calculation is duplicated in three places and already divergesArchitecture
- Observed
- Discounts are calculated in the API, in the frontend cart and when the invoice is generated. For bulk discounts two of the copies give different results.
- Evidence
- pricing.ts, cart/total.tsx, invoices/build.ts (fictional paths); the mismatch is shown by a test case.
- Business impact
- The cart total may not match the invoice, and every pricing change has to be made in three places.
- Recommendation
- Keep a single calculation on the server and only display it on the frontend; cover edge-case discounts with tests.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P2 · M
- Limitations
- Retail and bulk discount scenarios were checked; promo codes were out of scope.
F-05MEDIUMThe main journey has no tests and releases are deployed by handTests and releases
- Observed
- Tests exist but cover utilities; the “create order → pay → get invoice” journey is not covered. Deployment is a manual script run from one developer's machine.
- Evidence
- The tests/ folder and coverage report, a deploy.sh script (fictional); CI only runs the linter.
- Business impact
- Customers are the first to notice breakages in the main journey; releases and rollbacks depend on one person.
- Recommendation
- Add an end-to-end test for the main journey, move deployment into CI with rollback, document the release procedure.
- Confidence · reproducibility
- HIGH · CONFIRMED
- Priority · effort
- P2 · M
- Limitations
- Behaviour under load was not assessed.
Demonstration sample. The company, product, code, file paths and commits are fictional. Severity reflects consequences weighted by likelihood; confidence reflects how well the fact is proven. S / M / L is a relative effort class, not an estimate in hours.
Where to go next
How the audit works
- 01
Brief
What worries the business and which decisions are ahead: growth, a new contractor, a deal. No code or secrets in the brief. We provide a scope and cost estimate after the brief.
- 02
NDA and access
NDA on your template or ours. Repository access is read-only, through a separate account.
- 03
Scope
We agree in writing which systems, domains and environments are reviewed, which methods are allowed and what stays out of scope.
- 04
Diagnostics
A manual, domain-by-domain review, with tools in support. We record facts: file and lines, configuration, a reproducible check.
- 05
Report
A summary for the owner and findings for the team: severity and confidence kept separate, review limitations stated openly.
- 06
Priorities and roadmap
Order of work: risk to users and the business → dependencies → effort. The plan is self-contained — any team can execute it.
Get your project assessed before development starts
Describe the task in the form below — we reply within a business hour and suggest the next step: a call, a review or an estimate.
What exactly we check
We go domain by domain within the agreed scope: from the access model and the database to the release process. Tools play a supporting role: a dependency scanner finds known vulnerable versions, but not flaws in business logic, authorization or architecture. Manual review finds those.
- Architecture and APIs
- Authorization and roles
- Secrets and dependencies
- Databases and migrations
- Backups and restore
- Tests for critical journeys
- CI/CD and rollback
- Logs and monitoring
Integration audit
We separately examine connections to external systems: payments, 1C, Kaspi, CRM, messengers. Errors at these seams are a common cause of lost orders and data discrepancies, so we review integrations down to API contracts and failure handling.
1C, Kaspi, Payment services, AmoCRM, Bitrix24, WhatsApp, Telegram, REST API
Sample teardown
Questions about the technical audit
The cost is set after the brief and once the scope is agreed: a landing page, a web application and an ERP with a dozen integrations are very different amounts of work. We provide a timeline and cost estimate after the brief.
An audit is an evidence-based review of code, architecture and configuration within an agreed scope. A penetration test is separate work under written rules of engagement, where testers try to exploit vulnerabilities. It is not part of the audit, and InterLAB does not currently offer it as a service; the audit report can help narrow the scope of such a test if you need one.
A two-level report: a summary for the owner — the main risks and the order of action — and technical findings for the team, with evidence, recommendations and review limitations. Plus a remediation roadmap. The report is self-contained: your team or any other contractor can work from it.
No. The audit shows the risks found within the reviewed scope and explicitly names what was not reviewed. It does not replace certification or confirm compliance with a standard: we use OWASP ASVS and the API Security Top 10 as reference points, not as a certificate.
Partially: performance, the external surface and infrastructure can be assessed from the outside. But architecture and code review require repository access. We work under NDA, with read-only access. Please do not send code, passwords or keys through the form or a messenger — we agree how to share access after the brief.
Yes, if growth is ahead: new features, higher load, integrations or a team change. An audit before scaling costs less than incident analysis afterwards.
No. The audit is a standalone service with a complete deliverable: the report and the plan. You can execute it with your own team or another contractor; if needed, we take on fixes and further development under a separate contract.
Deep dives in the blog
Related services
Discuss an audit
Describe the product and what worries you — no code, passwords or keys. We will suggest a review level and scope, and estimate time and cost after the brief.
- The first short conversation is free — we choose the format
- NDA — yours or ours
- Pricing after a brief and an agreed scope