Application Security Audit: What It Covers Beyond a Scanner

A hypothetical example. A fintech company is being vetted by a large corporate customer, and the supplier questionnaire asks: "Has an application security audit been carried out?" The team has an automated scanner report several dozen pages long, and it contains not a single critical finding. It is tempting to answer “yes”, but a scanner report alone does not establish that an audit meeting the customer’s required scope took place.

In substance, the scanner never logged into the customer portal under two different roles. It never tried to open another customer's payment order by swapping an identifier in an API request. It did not check whether an operation could be confirmed by skipping the approval step. It did not read the configuration or look at how the code builds database queries. If the customer one day asks not "was there an audit" but "what exactly was tested", the answer will be awkward.

This situation is invented, but the gap between "we have a report" and "the defences have been tested" comes up all the time. An application security audit is broader than any tool. It is a structured, agreed review of whether protection mechanisms actually withstand realistic risks: in the architecture, the code, the configuration, the APIs and the business logic.

Which Decision the Audit Must Support

Finding Vulnerabilities or Verifying Compliance

NIST SP 800-115 describes technical testing as planning and conducting tests, analysing the results and developing mitigation measures. It also notes that such work can serve two purposes: finding vulnerabilities, or verifying compliance with a policy or other requirements.

That duality defines scope. An audit whose goal is to find exploitable weaknesses before a release needs a different depth and timeline from a check of compliance with an internal policy or a customer requirement. So the first question for whoever commissions the audit is this: which decision must it support? A release, supplier acceptance, a remediation plan, or material for a regulator and customers?

For SaaS companies that regularly answer customer questionnaires this question matters especially; we covered how to structure testing for that scenario in our piece on penetration testing for SaaS companies.

Written Scope and Authorisation

Scope is recorded in writing together with explicit authorisation from the system owner. The document lists environments, accounts and roles, APIs and third-party components, testing windows, contacts and the person who can stop the work. It also states whether there will be access to source code and documentation: that determines whether the audit is "white box" or an external review.

If you have not yet decided what scope your application needs, you can put it together with the Pentest.red team on the pentest scope preparation page: systems, roles, access and the expected outcome are recorded there before any work begins.

Nothing in this article implies a right to test systems without written authorisation from their owner.

Why a Scanner Report Is Not an Audit

What a Scanner Does Well

Automated tools quickly crawl a large number of pages and requests and find known error patterns, outdated components, missing headers and typical injections. This is useful, cheap and fits well into the development pipeline. Nobody is suggesting you give up scanners.

Where It Is Blind

A scanner does not know what your application means. It does not understand that a user of company A must not see company B's invoice when both requests are syntactically valid. It does not know that an application cannot be approved before the documents are checked. It rarely works with several roles at once and cannot see the code that makes access decisions. Authorisation and business logic errors, which often turn out to be the most expensive, sit exactly in its blind spot.

There is a more mundane problem too: coverage. If the scanner could not authenticate or lost its session halfway through the crawl, it will dutifully test the login page and a few public sections. Zero critical findings in such a report means little was tested, not that a lot is protected. So the first question to ask about any automated report is which sections and endpoints it actually visited and under which accounts.

An audit is not the opposite of a scanner: it includes automated checks as one of its tools, but adds what automation cannot provide, namely understanding of the system and manual verification.

Architecture: Where the Audit Begins

Trust Boundaries and Data Flows

An audit starts with understanding how the application is built. Where does the user authenticate, where are access decisions made, which services trust each other without re-checking, where does data go? Every place where data crosses a trust boundary, from the browser to the API, from the gateway to an internal service, from the application to an external payment provider, gets its own set of checks.

In distributed systems the architecture stage is especially important: the error is often not in one service but in the assumption that "the request was already checked before it reached us". How to plan testing in such systems is described in our guide to microservices penetration testing.

Documentation Versus Reality

Architecture diagrams, API specifications and role descriptions are a useful starting point, but the auditor checks whether they match reality. An endpoint that is not in the documentation but still answers requests. A role that is "read-only" on paper but can modify records in practice. A service that the diagram shows as unreachable from outside but that actually accepts requests from the internet. Discrepancies between documentation and reality are a frequent source of findings.

Code and Configuration

Risk-Based Code Review

If source code access is available, a full line-by-line read is usually neither necessary nor realistic. A risk-based review is more effective: the auditor works from the threat map towards the places where decisions are made. How are permissions checked? How are database queries and OS calls built? How are uploaded files handled? How are tokens issued and validated? Where are secrets stored?

A classic example is command injection. An OWASP ASVS requirement states directly that OS calls must use parameterised queries or contextual command-line output encoding. You can find a single vulnerable point from the outside. Seeing that it is a systemic pattern in the codebase is only possible by looking at the code.

Configuration, Secrets and Dependencies

Many vulnerabilities live not in the code but in settings: debug mode in production, verbose error messages, excessive permissions on a service account, secrets in environment variables visible to too many people, outdated libraries with known vulnerabilities. The audit checks application and environment configuration within agreed limits and records which components were available for review and which were not.

With third-party components it is important not to overstate conclusions. An audit can show that a library version with a known vulnerability is in use and whether the vulnerable code is reachable from the application. But it does not test the security of the library itself or of a provider's entire cloud service. The report should make the distinction visible: "component is outdated", "vulnerable path confirmed" and "component not analysed" are three different statements.

HTTP and Browser Policies

A large part of a web application's protection is implemented through HTTP behaviour. HTTP is a stateless protocol, and cookies add state to it. So the auditor looks at how sessions are established through Set-Cookie and with which attributes, how authentication works, and whether redirects, caching and cross-origin interaction leak data.

Policies enforced by the browser are a separate area. Content Security Policy controls which resources a page may load and helps detect and mitigate cross-site scripting and data injection. CORS defines how a site responds to cross-origin requests. Permissions Policy and Cross-Origin-Resource-Policy restrict browser features and cross-origin loading. A mistake in these policies quietly weakens protection the code relies on. Tools such as HTTP Observatory are convenient for quick non-intrusive checks of authorised targets, but header hygiene is a supporting measure and does not replace testing of access control and logic.

APIs and Authorisation

Objects, Properties, Functions

Modern applications are first and foremost APIs, and the most serious API errors are usually about authorisation. The 2023 edition of the OWASP API Security Top 10 separates three distinct failures. Object-level authorisation: a user reads or changes someone else's object by substituting its identifier. Property-level authorisation: the API returns, or allows changes to, fields the user must not see or modify. Function-level authorisation: a user calls an operation intended for another role.

The object-level check may pass while the function-level check is missing. So the audit tests all three levels separately, with several roles and several test tenants, and records which endpoints and methods were covered.

The API Contract and Actual Behaviour

An API specification is a promise. The auditor checks how the API behaves beyond what was promised: with extra fields in the request, unexpected data types, old endpoint versions someone forgot to switch off, and bulk requests.

Two risks from the same list deserve special attention because scanners almost never assess them correctly. The first is unrestricted resource consumption: no limits on the rate, size and cost of requests. The second is unrestricted access to sensitive business flows, where a technically valid scenario such as registration, booking or sending a confirmation code can be automated at a scale that harms the business. Both risks sit at the junction of API and business logic and require an understanding of what normal behaviour looks like for the application.

The method for REST interfaces is covered in detail in our article on REST API security assessment.

Business Logic and Manual Verification

Where Automation Does Not Help

Business logic is the set of rules by which your particular application works. A discount cannot be applied twice. An application cannot be approved until the documents are uploaded. A transfer above a limit requires a second confirmation. A refund cannot exceed the amount paid. Breaking these rules does not look like an "error" to a scanner: every individual request is valid, and the problem lies in the sequence, the values or the roles.

What Manual Verification Looks Like

The auditor studies the application's processes, writes down the invariants that must hold and tries to break them within agreed limits. Can a step be skipped? Repeated? Can two actions be performed at the same time so that they conflict? Can a negative value be substituted? Can an operation be performed on behalf of a role that should not have it? Every such attempt is documented even if it did not lead to a finding: that is precisely the evidence of coverage.

Manual verification takes time, so it makes sense to concentrate it where errors cost the most: money, personal data, access rights, irreversible actions. A good audit plan states plainly which processes were verified manually and which only automatically, and why that choice was made. How to buy this kind of work is covered in our article on business logic security testing.

Standards as the Framework of the Method

What Matters, What to Verify, How to Test

Open standards cover different levels of an audit and complement each other well. The OWASP Top 10, in its 2025 edition, is an awareness document reflecting consensus on the most critical web application risks. It is useful for framing the task and talking to management, but it is a list of risks, not a set of verifiable requirements.

OWASP ASVS 5.0.0 is closer to an audit baseline: it provides a basis for testing technical security controls and aims to normalise the range of coverage and rigour of verification on the market. ASVS recommends citing requirements together with the version. For example, v5.0.0-1.2.5 means the fifth requirement in the injection prevention section of the encoding and sanitisation chapter of version 5.0.0. Without the version, a reference loses meaning over time because numbering changes. OWASP WSTG, whose stable release is 4.2 with version 5.0 in development, defines the test procedures. SP 800-115 describes planning, execution and post-execution assessment activities, including analysis of findings, mitigation recommendations and reporting.

Together it works like this: the Top 10 and CWE answer "what matters", ASVS answers "what to verify", WSTG and SP 800-115 answer "how to test", and governance frameworks answer "what to do with the outcome".

1. Decision and scopeName the decision the audit supports and record environments, roles, APIs and code access.
2. RequirementsChoose a versioned set of ASVS requirements that matches the application's risk and the audit goal.
3. ChecksCombine architecture analysis, code review, configuration review, API tests and manual logic verification.
4. ConfirmationReproduce every finding, discard false positives, and map it to a CWE and an ASVS requirement.
5. Report and retestAssess risk in business context, assign owners and retest the fixes.

Weakness Classes Instead of a Task List

The CWE Top 25 ranking highlights the most dangerous and widespread software weaknesses. MITRE also publishes a list of weaknesses actively exploited according to the CISA KEV catalogue and a list of weaknesses "on the cusp" of the Top 25. For an auditor this signals which root causes recur and attract attackers.

Mapping to CWE changes the remediation conversation. Instead of fixing one vulnerable parameter, the team asks whether there is a systemic pattern in the code. CWE notes that working on root causes helps eliminate whole classes of defects, for example those related to injection or memory safety. CISA's Secure by Design alerts on eliminating cross-site scripting, OS command injection and directory traversal as classes point the same way. A report that groups findings by class gives engineering leadership a roadmap rather than just a list of tickets.

Report Acceptance and Retesting

What "No Findings" Means

Every finding in the report should record the requirement tested, the observed evidence, reproduction steps, affected assets, a risk rating in business context and a confidence level. But what the report says about the absence of findings matters just as much. "No vulnerabilities found" means nothing without stating which requirements were tested, with which methods, under which roles and within what time.

An audit is not a certificate and not proof that no vulnerabilities exist. If scope or time limited the review, the report must say so plainly. An honest list of what was not tested is a sign of quality work, not of weakness.

Retesting Against the Same Requirements

A fix counts as confirmed only once it has been retested against the same ASVS requirements of the same version, with the same methods and, where possible, the same test data. A retest should look not only at the specific point but at the class: if one injection was fixed, does the same construct exist in neighbouring modules? We describe how to organise a retest that actually proves remediation in our piece on penetration test remediation validation.

The Audit in Risk Management

Owners and Deadlines

An audit only adds value if findings enter a managed process. The NIST Cybersecurity Framework 2.0 helps organisations understand cyber risk and improve how they manage it; it offers profiles and informative references to NIST resources. If audit results are placed in a CSF-aligned profile, it becomes easier to compare current and target states over time.

A finding's priority is determined not only by a technical rating but by business context. The same authorisation error in an admin panel used by three employees and in a payment service's public API are different risks. A good report explains why a finding was given its priority, so that the risk owner can agree with or challenge the assessment.

Operationally this means assigning an owner and a deadline to each weakness class, retesting fixes, and feeding recurring classes back into architecture review and developer training. The most common mistake here is a mismatch: a scanner report is used as evidence for a decision that demands high assurance, or an expensive manual audit is left without a remediation owner.

If You Are a Buyer, Not a Developer

CISA's Secure by Design position adds a dimension of accountability: technology suppliers should take ownership of security at the leadership level, and products should ship with multi-factor authentication, logging and single sign-on at no extra cost. For product teams, findings about missing logs or weak authentication are a design issue, not just a defect. For buyers, CISA's Secure by Demand guidance helps ask these questions during procurement. It is worth requesting a supplier's commitments, but a commitment is a statement, not an audit result.

Let us return to the questionnaire from the hypothetical example. A good answer to the customer's question is not "yes, there was an audit" but a short description: which decision it supported, which requirements and areas were tested, with which methods, what was found, what was fixed and confirmed by retesting, and what remained out of scope. If you want to work out in advance which testing format suits your application and what result your decision needs, you can do that with us while preparing the pentest scope. The general format of our work is described under penetration testing services.