Web application security audit

When an audit is a sensible first step

Before an important feature goes live

The application is about to gain a new sign-in flow, payments, a customer portal, employee roles, an integration or an API. You want the agreed area checked before it begins handling real users and data.

After changing supplier or taking over a system

You have a working application, but you do not know which decisions concerning access, configuration and data protection have already been verified. An audit can separate urgent issues from work that can be planned for later.

Before a major expansion

New roles, modules or integrations are planned. Reviewing the existing constraints first helps prevent current weaknesses from being carried into the next parts of the system.

When the application behaves in a worrying way

Users can see information they should not have access to, sign-in behaves inconsistently, the API returns too much data or the configuration raises concerns. We first determine whether the situation calls for a planned audit or urgent incident handling.

When you need a repair order, not another warning list

An automated scan does not tell you which findings are actually reproducible in this application or which matter most to the business. You need confirmation, context and priorities.

An audit, configuration review, code review and penetration test are not the same thing

These service names are sometimes used interchangeably, although the work behind them can differ considerably. Before starting, we therefore state in the proposal which activities are included.

We use the term "penetration test" only when the engagement actually includes agreed penetration testing. A security audit alone is not a promise of a full pentest.

We agree the scope before work begins

Every application has its own sign-in flow, roles, data, integrations and risks. Before preparing the quote, we establish at least:

• the domains, applications and environments in scope;
• the functions and business processes to be reviewed;
• the roles and test accounts that may be used;
• selected API endpoints and connected integrations;
• permitted types of testing and their limits;
• areas explicitly excluded from the engagement;
• safe operating conditions for test or production environments;
• the result format and the people authorised to receive it.

If any part of the application, infrastructure or source code is outside the engagement, we record this as a limitation. The result then cannot be mistaken for coverage of areas we did not examine.

How the engagement can work

1. We briefly qualify the need

A free call of up to 20 minutes helps us understand the objective, important areas and materials that may be needed. It is not a free diagnosis, audit or report.

2. We define the scope and safety rules

Before starting, we provide an individual proposal. It states the environment, permitted actions, exclusions, deliverables, timing and price.

3. You provide the required materials securely

Once the engagement is agreed, we select an appropriate channel for test accounts, source code or documentation. Do not send passwords, API keys, database copies or customer data through the ordinary contact form.

4. We perform the agreed checks

We use only the methods appropriate to the scope and conditions of the application. Where possible and safe, we confirm issues instead of forwarding an unverified list of automated warnings.

5. We deliver the result and discuss priorities

The result explains what was examined, what was confirmed, which limitations apply and where remediation should begin. We agree the format before work starts.

What you receive after the audit

The exact deliverables depend on the proposal. The agreed summary may include:

• the examined scope, environment and limitations;
• confirmed findings with an assessment of their severity;
• evidence and reproduction steps where these can be shared safely;
• the possible technical and business impact;
• recommendations for remediation or further investigation;
• a proposed order of work;
• technical information for the team implementing the changes.

You can use the material in follow-up work with Domin Software or pass it to another chosen supplier, subject to confidentiality and the agreed rules for handling the report.

OWASP is a reference point, not an automatic promise of full coverage

When defining the scope, we may use current OWASP materials on web application testing, security requirements and API risks. They help organise the areas to be reviewed, but they do not replace an engagement-specific scope.

A reference to OWASP does not mean that every engagement includes all Web Security Testing Guide tests, verification of every ASVS requirement or every category of API risk. The proposal states what will actually be checked.

What the basic scope does not include

Unless a specific proposal states otherwise, an audit does not automatically include:

• a security certificate;
• a guarantee that every vulnerability will be found or that no future issue will appear;
• testing of all source code, infrastructure, networks and devices;
• social-engineering tests or actions directed at employees;
• load testing or disruption of production services;
• implementation of every recommended fix;
• round-the-clock monitoring or permanent incident response;
• a new review at any later date or after unagreed changes.

We conduct active testing in production only when it has been separately agreed, authorised and safeguarded. If safe testing requires another environment, we explain this before starting.

Remediation and retesting

Implementing fixes is a separate scope unless the proposal explicitly says otherwise. After the audit, we can quote for the work or provide the findings to the team selected by the client.

If Domin Software implements the fixes, retesting may be included at no additional charge for the period stated in the proposal. A longer break, changes made by another party or work outside the original scope require a new quote.

If the audit leads to a larger project delivered by Domin Software, the paid audit fee is credited towards the total project cost.

Timing, quote and payment

Every audit is quoted individually. The price depends on factors such as the number of areas, roles, endpoints and environments, the access required and the permitted types of testing.

As a working estimate, allow 7 to 15 business days after the complete scope, an available environment and agreed test accounts have been provided. The final schedule is stated in the proposal.

Payment is normally due after the agreed stage has been completed. For a larger engagement, we may agree a deposit.

Frequently asked questions

How does a security audit differ from a penetration test?

An audit is the broader term for a paid assessment of agreed areas. It can combine configuration review, analysis of selected functions, code review and testing. A penetration test involves controlled attempts to exploit vulnerabilities within explicitly authorised boundaries. Not every audit includes one.

Can testing be carried out in production?

We do not assume this by default. First, we assess the risk and determine whether a test environment is sufficient. Any action in production requires separate permission, limited scope and conditions that protect data and service availability.

Do you need access to the source code?

Not always. It depends on the objective and scope. Some issues can be assessed through the running application, while others require configuration, documentation or selected parts of the code. We establish the necessary access before quoting.

What is included in the audit summary?

We describe the examined scope and its limitations, confirmed findings, their severity, available evidence, reproduction steps, risk and recommendations. The precise format and level of detail are agreed in the proposal.

Does the audit include implementing fixes?

Not in the basic scope. We can quote for implementation separately, or you can give the audit material to another supplier.

Is retesting included in the price?

If Domin Software implements the fixes, free retesting may apply for the period specified in the proposal. After a longer break, following other changes or outside the agreed scope, we prepare a new quote.

Does an audit guarantee that the application has no vulnerabilities?

No. The result applies to a defined scope, time, environment and set of available information. It is not a guarantee that every issue has been found or that no future vulnerability will arise.

How should access and test accounts be provided?

Use the form only to describe the situation and required scope. Once the engagement is agreed, we will specify a secure way to transfer the materials. Do not enter passwords, API keys, customer data or a database copy in the form.

What to include in your first message

You can tell us:

• what type of application it is and how important it is to the business;
• why the audit is needed, for example before a launch, after changing supplier or before a major expansion;
• whether a test environment is available;
• how many important user roles the application has;
• whether it exposes an API or relies on important integrations;
• the expected timeframe and why the review is needed now;
• known access limitations, without sharing secrets.

Do not send passwords, API keys, tokens, database copies, source code or customer data through the form. We will agree a secure transfer method separately.

CTA: Define the audit scope

If you are taking over an existing system from another supplier, you can first use the application handover checklist.

After the audit, we can separately agree application modernisation or ongoing maintenance. An AI-built application audit is available for projects created with AI tools, while response-time and load problems belong in an application performance audit.

Technical references

• OWASP Web Security Testing Guide - a reference for web application and web service testing areas that must be adapted to the actual engagement.
• OWASP Application Security Verification Standard - a catalogue of technical requirements that can support the definition of security and verification scope.
• OWASP API Security Top 10 - a reference for risks specific to APIs.

The public copy does not claim full compliance with all of these materials.