Web Application Security Audit: OWASP 2025 Method

A web application security audit tests authorised functionality, roles, APIs, sessions, input handling and deployment controls for reproducible weaknesses. Agree test accounts, allowed exploitation, data handling, rate limits and emergency contacts before sending active payloads.

The OWASP Top 10 is the most widely recognised framework for web application security. Published by the Open Worldwide Application Security Project, it represents the ten most critical security risks facing web applications, compiled from real-world breach data and expert consensus. It is used as a baseline by security auditors, development teams, and regulatory frameworks worldwide.

This guide explains the OWASP Top 10 categories most relevant to web application audits, shows you what each vulnerability looks like in practice, and provides a testing methodology you can follow to assess your own application.

What Is a Web App Audit

A web application security audit is a structured assessment of a web application's security controls, code quality, and infrastructure configuration. It differs from a general website security scan in several important ways.

A website security scan checks external-facing elements: SSL certificates, security headers, CMS vulnerabilities, and blacklist status. It treats the site as a black box and tests from the outside. A web application audit goes deeper. It tests the application's logic, authentication mechanisms, data handling, API security, and inter-component communication. It often includes source code review, authenticated testing across multiple user roles, and manual exploitation attempts.

Web application audits are essential for any application that handles user data, processes transactions, manages user accounts, or exposes APIs. This includes SaaS products, ecommerce platforms with custom functionality, customer portals, internal business tools exposed to the internet, financial applications, and healthcare platforms. If your application does more than serve static content, it needs a web application audit, not just a surface scan.

The scope of a web application audit typically covers the application itself (all pages, forms, and features), its APIs (REST, GraphQL, webhooks), the authentication and authorisation system, session management, data storage and transmission, third-party integrations, and the deployment infrastructure. The audit produces a report listing discovered vulnerabilities with severity ratings, evidence, and remediation guidance.

OWASP Top 10

The OWASP Top 10 is updated periodically to reflect the evolving threat landscape. The current version organises web application risks into ten categories ranked by prevalence and impact. Use the categories to discuss risk, then map the application's actual requirements to verifiable controls and tests.

The current OWASP Top 10:2025 categories are:

1. A01 Broken Access Control — users can act outside their intended permissions.
2. A02 Security Misconfiguration — unsafe defaults or deployment and cloud configuration expose functionality or data.
3. A03 Software Supply Chain Failures — compromised or unmanaged build, dependency and distribution paths affect integrity.
4. A04 Cryptographic Failures — unsuitable or incorrectly implemented cryptography exposes protected data.
5. A05 Injection — untrusted input changes a query, command or interpreter operation.
6. A06 Insecure Design — missing or ineffective design controls create systemic risk.
7. A07 Authentication Failures — identity, credential or session controls can be bypassed or abused.
8. A08 Software or Data Integrity Failures — the application trusts code or data without sufficient integrity checks.
9. A09 Security Logging and Alerting Failures — events are not recorded, detected or escalated effectively.
10. A10 Mishandling of Exceptional Conditions — error, resource or state handling creates insecure behaviour.

The OWASP Top 10 is an awareness document and a starting point, not a complete test plan. Define verifiable requirements from the application and threat model with OWASP ASVS, then select applicable WSTG tests within the authorised scope.

Injection Attacks

Injection vulnerabilities occur when an application sends untrusted data to an interpreter — a database engine, an operating system shell, an XML parser, or an LDAP directory — without proper sanitisation. The attacker's input is treated as code rather than data, allowing them to execute commands, read data, modify records, or gain system access.

SQL injection remains the most common and dangerous injection type. It works by inserting SQL commands into input fields that are concatenated directly into database queries. A login form vulnerable to SQL injection might accept the input ' OR '1'='1 as a username, which modifies the query logic to return all user records, bypassing authentication entirely.

Modern SQL injection is more sophisticated than this textbook example. Blind SQL injection techniques extract data one bit at a time through true/false questions in query responses. Time-based blind injection uses database sleep functions to infer information based on response timing. Second-order injection stores malicious input in the database and triggers it when the data is used in a subsequent query.

Map input points such as form fields, URL parameters, headers, cookies and API bodies, then select non-destructive tests within the written authorisation. Tools such as SQLMap send active payloads and require explicit approval and safe settings. Where source is available, trace untrusted data to interpreters and verify parameterised interfaces or equivalent controls.

Other injection types to test for include command injection (user input executed as OS commands), LDAP injection (manipulating directory queries), XPath injection (attacking XML data stores), and template injection (executing code through template engines). The prevention principle is the same across all types: never treat user input as executable code, and always use the language or framework's built-in parameterisation features.

Broken Authentication

Authentication failures allow attackers to compromise user accounts, impersonate legitimate users, and gain unauthorised access to protected functionality. These vulnerabilities are particularly dangerous because they provide a legitimate-looking entry point — once an attacker controls a user account, their malicious activity blends in with normal usage.

Common authentication vulnerabilities found in web application audits include weak password policies that allow short or common passwords, missing or bypassable multi-factor authentication, session tokens that are predictable or do not expire, credential stuffing vulnerability where the application does not rate-limit login attempts, password reset flows that can be manipulated to reset other users' passwords, and session fixation where an attacker can force a user to authenticate with a session token the attacker already knows.

Auditing authentication requires testing each of these areas systematically. Attempt to create accounts with weak passwords to verify policy enforcement. Test login rate limiting by sending rapid authentication requests. Analyse session tokens for randomness and entropy. Walk through the password reset flow looking for information disclosure, insecure token generation, or steps that can be skipped. Test whether logging out actually invalidates the session token on the server side.

Pay special attention to authentication in API endpoints. Web application UIs often have stronger authentication controls than the underlying APIs because developers focus security effort on the visible interface. An API that accepts requests with expired or invalid tokens — or no token at all — is a critical finding regardless of what the front-end enforces.

XSS

Cross-site scripting occurs when an application includes untrusted data in web page output without proper encoding. This allows attackers to inject client-side scripts that execute in other users' browsers. XSS attacks can steal session cookies, redirect users to phishing sites, modify page content, capture keystrokes, and perform actions on behalf of the victim user.

There are three main types of XSS. Reflected XSS is the most common — the attacker's script is included in a URL parameter and reflected back in the page response. The attack requires the victim to click a crafted link. Stored XSS is more dangerous — the attacker's script is saved in the application's database (through a comment form, profile field, or message) and served to every user who views the affected page. DOM-based XSS occurs when client-side JavaScript processes attacker-controlled data and writes it into the DOM unsafely.

To audit for XSS, inject test payloads into every input the application accepts and check whether the payload is rendered in the response without encoding. Start with basic payloads like script tags and event handlers, then escalate to bypass techniques if initial payloads are filtered. Test both reflected scenarios (payloads in URL parameters and form submissions) and stored scenarios (payloads saved through user-generated content features).

Prevention requires context-aware output encoding. HTML contexts need HTML encoding. JavaScript contexts need JavaScript encoding. URL contexts need URL encoding. CSS contexts need CSS encoding. A Content-Security-Policy header provides an additional layer of defence by restricting which scripts the browser is allowed to execute, even if an XSS vulnerability exists in the application code.

Security Misconfiguration

Security misconfiguration spans defaults, unnecessary features, permissive access, missing browser policies, verbose errors and unsupported software across application and infrastructure layers. Test the configurations present in the scoped architecture.

Common misconfigurations found in audits include default admin credentials on application frameworks or infrastructure components, directory listing enabled on the web server exposing file structures, debug mode enabled in production revealing stack traces and internal paths, unnecessary HTTP methods enabled (PUT, DELETE, TRACE), cloud storage buckets configured as publicly accessible, CORS policy set to allow all origins, and database ports exposed to the internet without access restrictions.

Auditing for misconfigurations involves checking each layer of the stack: the web server, the application framework, the database, the operating system, and any cloud services. Review configuration files against hardening guides. Check for default accounts and credentials. Verify that error handling does not expose sensitive information. Test whether administrative interfaces are exposed to the internet.

Remediation may involve configuration, code, infrastructure or operational change. Rank each verified issue from exposure, exploitability, affected assets and impact, then let the implementation owner estimate effort and regression risk.

Testing Methodology

Use the authorised scope, ASVS requirements and applicable WSTG tests to create a traceable method. Record exclusions and untested areas because no generic methodology ensures complete coverage.

Phase 1: Reconnaissance and mapping. Before testing begins, build a picture of the authorised application. Identify pages, forms, API endpoints, file uploads and administrative interfaces. Map user roles and intended access. Document the observable technology stack and third-party boundaries, marking uncertain inferences as such.

Phase 2: Tool-supported testing. Configure approved tools against the allowed routes and roles. Preserve raw requests and responses, and manually verify alerts because scanners can miss application logic and produce false positives.

Phase 3: Manual testing. Work through the agreed WSTG areas and business flows. Test relevant roles, state changes and APIs within the written rules of engagement. Time allocation depends on scope and findings.

Phase 4: Exploitation and validation. Where the rules of engagement allow it, use the least harmful proof needed to confirm a finding and impact. Document reproducible steps, requests and responses, affected roles and data, cleanup and business context.

Phase 5: Reporting and remediation guidance. Compile verified findings with affected assets, preconditions, evidence, reproduction steps, impact, confidence, severity rationale and remediation. Record false positives and untested areas, then retest fixes within the same conditions.

After remediation, retest the original reproduction steps and relevant neighbouring controls. Use the official OWASP Top 10:2025, Application Security Verification Standard and Web Security Testing Guide. The security tools guide explains what each scanner can support.