Web Application Security Testing: How to Do It Step by Step (2026)

Web application security testing is the process of identifying, validating, and prioritizing weaknesses that could let an attacker access data, impersonate users, execute unauthorized actions, disrupt services, or compromise the underlying infrastructure. It combines automated analysis with manual testing of code, configuration, authentication, access control, APIs, business logic, dependencies, and runtime behavior.

The objective is not to produce a clean scanner report. It is to determine whether a realistic attacker can cross a trust boundary and create meaningful business impact.

Why web application security testing matters

Web applications expose authentication endpoints, APIs, third-party integrations, customer data, administrative functions, and business workflows to the internet. A weakness in any of these components can give an attacker a path into the wider system.

The 2025 Verizon Data Breach Investigations Report analyzed more than 22,000 security incidents and 12,195 confirmed breaches. Credential abuse accounted for 22% of initial access, while vulnerability exploitation accounted for another 20%. Third-party involvement doubled to 30% of breaches.

The financial consequences remain significant. IBM’s 2026 Cost of a Data Breach Report places the global average breach cost at $4.99 million. The report also found that one in four malicious breaches involved AI-enabled attacks and cost an average of $6 million.

Security testing reduces risk by answering practical questions:

• Can one customer access another customer’s records?
• Can an unauthenticated user reach an internal API?
• Can input be turned into SQL, operating-system, or template commands?
• Can a normal user acquire administrative permissions?
• Can stolen credentials bypass existing controls?
• Can an attacker manipulate prices, limits, workflow states, or transactions?
• Will the application expose secrets through errors, logs, or source maps?
• Can a compromised dependency or build artifact reach production?
• Will suspicious activity generate an alert that somebody receives?

A scan may help with some of these questions. It cannot answer all of them.

OWASP Top 10 web application security risks for 2026

The current edition is the OWASP Top 10:2025. It was built from data contributed for more than 2.8 million applications and introduced two new categories: Software Supply Chain Failures and Mishandling of Exceptional Conditions.

OWASP also reports that Broken Access Control remains the leading category. An average of 3.73% of tested applications contained at least one associated weakness. Cryptographic Failures affected an average of 3.8%, while Security Misconfiguration affected 3%.

The Top 10 is an awareness and prioritization document—not a complete test plan. Still, it provides a useful starting point.

Use the Top 10 to organize risk discussions, then expand the scope according to the application’s architecture, data, users, and threat model.

For a more testable requirements baseline, the OWASP Application Security Verification Standard provides structured security requirements. Its current stable version, ASVS 5.0.0, can be used to define coverage and the required level of verification.

Types of web application security testing

No single security testing method sees the entire application. Effective coverage requires techniques that examine code, dependencies, runtime behavior, deployed configuration, and business logic.

SAST: static application security testing

SAST should run early, ideally during development and on pull requests. It analyzes code without sending requests to a deployed application.

Use SAST to detect:

• unsafe string construction;
• missing validation;
• hardcoded passwords and tokens;
• weak cryptography;
• insecure deserialization;
• path traversal;
• dangerous function calls;
• unescaped output;
• authentication and authorization mistakes.

A finding should be reviewed in context. A flagged function may be unreachable, protected by another control, or genuinely exploitable. Treat SAST as a fast feedback mechanism, not an automatic vulnerability verdict.

DAST: dynamic application security testing

DAST treats the deployed application as a black box. The scanner crawls available pages and endpoints, submits test payloads, and analyzes responses.

It is useful for detecting:

• injection;
• cross-site scripting;
• unsafe headers;
• TLS and cookie problems;
• exposed files;
• default pages;
• directory traversal;
• server information leakage;
• some authentication and session issues.

DAST coverage depends on what the scanner can reach. If it cannot authenticate correctly, understand a multi-step workflow, or discover an undocumented API, important attack surfaces may remain untested.

IAST: interactive application security testing

IAST combines runtime testing with internal instrumentation. An agent observes code execution, data flow, libraries, and requests while functional or security tests interact with the application.

This additional context can reduce false positives and help developers identify the responsible code. However, IAST finds only paths exercised during testing. Weak functional coverage creates weak IAST coverage.

Penetration testing

Penetration testing is a controlled attempt to exploit vulnerabilities and demonstrate their effect. It should go beyond confirming that an individual issue exists.

A penetration tester may chain several apparently moderate weaknesses:

The value lies in showing realistic attack paths and business impact. Organizations needing this level of adversarial assessment should engage qualified penetration testing services rather than relying only on automated scanning.

How to perform web application security testing step by step

Step 1: Define the scope and authorization

Security testing must begin with written authorization and an agreed scope.

Document:

• domains, subdomains, APIs, and IP ranges;
• environments that may be tested;
• excluded systems;
• permitted test techniques;
• test accounts and roles;
• acceptable testing hours;
• rate limits;
• data-handling rules;
• incident and escalation contacts;
• conditions for stopping the test.

Do not assume that a third-party integration can be tested because the application uses it. The provider may prohibit scanning or simulated attacks.

Production testing requires additional caution. Destructive payloads, denial-of-service techniques, mass data access, and persistence mechanisms should normally be excluded unless explicitly approved and controlled.

Step 2: Map the architecture and attack surface

Create an inventory of everything that accepts input, makes trust decisions, processes sensitive data, or communicates across a boundary.

Include:

• browser interfaces;
• REST, GraphQL, and WebSocket APIs;
• authentication providers;
• administrative portals;
• microservices;
• databases and storage;
• file uploads;
• webhooks;
• message queues;
• cloud services;
• third-party scripts and SDKs;
• CI/CD pipelines;
• package registries;
• monitoring and support tools.

Record where data enters, how it moves, where it is stored, and which identity or service account can access it.

Unlinked endpoints and old API versions deserve special attention. An endpoint does not stop being an attack surface because the current UI no longer uses it.

Step 3: Classify assets and data

Security effort should reflect the value and sensitivity of the protected assets.

Identify:

• credentials and session tokens;
• personal data;
• financial information;
• health records;
• payment details;
• intellectual property;
• administrative functions;
• encryption keys;
• audit records;
• business-critical workflows.

Map applicable requirements such as PCI DSS, HIPAA, GDPR, SOC 2 controls, or contractual security obligations. Compliance does not replace threat-based testing, but it affects the minimum expected coverage and evidence.

Step 4: Build a threat model

Threat modeling asks what an attacker wants, where they can enter, which trust boundary they must cross, and what controls are expected to stop them.

For each critical flow:

For an eCommerce checkout, abuse cases might include changing prices, reusing discounts, bypassing inventory checks, submitting a negative quantity, replaying payment callbacks, or creating duplicate refunds.

These scenarios will not necessarily be discovered by a generic vulnerability scanner.

Step 5: Review authentication

Authentication testing should cover more than entering a correct password.

Test:

• account enumeration;
• credential stuffing resistance;
• rate limiting;
• password policy;
• MFA enforcement and bypass attempts;
• password reset;
• email and phone verification;
• recovery codes;
• remember-me behavior;
• SSO and OAuth flows;
• inactive and locked accounts;
• default credentials;
• error messages;
• session creation after authentication.

Credential attacks should be treated as ordinary threat scenarios. Verizon’s analysis of credential stuffing activity found that it represented a median of 19% of daily authentication attempts in the examined SSO data. The rate reached 25% for enterprise organizations, and the highest single-day value was 44%.

Confirm that defenses work without making the application unusable for legitimate customers.

Step 6: Test session management

After login, verify how the application creates, stores, rotates, and invalidates sessions.

Check whether:

• session IDs are unpredictable;
• cookies use Secure, HttpOnly, and appropriate SameSite attributes;
• session identifiers change after authentication or privilege changes;
• logout invalidates the server-side session;
• password changes terminate relevant sessions;
• expired tokens cannot be refreshed indefinitely;
• concurrent-session rules work;
• sensitive tokens appear in URLs, logs, or browser storage;
• stolen or replayed tokens remain usable;
• inactivity and absolute timeouts match requirements.

JWT validation should include signatures, algorithms, key selection, audience, issuer, expiry, and privilege claims. Decoding a JWT is not the same as validating it.

Step 7: Verify authorization at every layer

Broken access control is not limited to hidden administrative pages. Test permissions for every sensitive action and object.

Cover:

• horizontal access between users;
• vertical access between roles;
• tenant isolation;
• direct object references;
• API object-level authorization;
• function-level authorization;
• field-level authorization;
• bulk operations;
• file and export access;
• indirect access through reports or search;
• background jobs and webhooks.

A useful authorization matrix lists roles against resources and actions. Execute negative tests for every prohibited combination.

Never rely on disabled buttons or hidden navigation. Authorization must be enforced by the server for every request.

Step 8: Test input handling and output encoding

Identify every place where the application processes untrusted data:

• query parameters;
• forms;
• JSON bodies;
• headers;
• cookies;
• uploaded files;
• filenames;
• webhooks;
• database content;
• imported documents;
• third-party responses.

Test for:

• SQL and NoSQL injection;
• operating-system command injection;
• server-side template injection;
• cross-site scripting;
• path traversal;
• XML external entities;
• LDAP injection;
• header injection;
• log injection;
• open redirects;
• unsafe deserialization;
• server-side request forgery.

Validation should reflect the expected data type, format, range, length, and business meaning. Output encoding must match the context in which the value is used: HTML, JavaScript, URL, CSS, SQL, shell, or another interpreter.

Step 9: Test APIs separately

The browser interface does not expose every possible API request. Test APIs directly using their documented and observed contracts.

Verify:

• object- and function-level authorization;
• mass assignment;
• excessive data exposure;
• rate limiting;
• schema validation;
• pagination limits;
• GraphQL query depth and complexity;
• replay protection;
• idempotency;
• token scope;
• deprecated API versions;
• CORS;
• webhook signatures;
• error responses;
• inventory of public endpoints.

Modify identifiers, remove expected fields, add unexpected properties, change content types, reorder requests, and call endpoints outside the intended UI sequence.

Step 10: Test business logic

Business-logic vulnerabilities occur when individual requests are technically valid but their sequence or combination violates the intended rules.

Examples include:

• applying the same discount repeatedly;
• purchasing an unavailable item;
• using a negative quantity;
• skipping an approval step;
• transferring funds beyond a limit;
• claiming the same reward multiple times;
• changing a price after server validation;
• submitting concurrent requests to exploit a race condition;
• replaying a completed transaction;
• bypassing a subscription tier;
• modifying a workflow state directly.

Testers need domain knowledge and permission to experiment with unusual sequences. Automated scanners rarely understand what the business considers impossible.

Financial products need deeper coverage of race conditions, transaction integrity, third-party APIs, and regulatory controls. Our guides to penetration testing in fintech and security testing for fintech apps address those risks separately.

Step 11: Review security configuration

Review the deployed application and supporting infrastructure for:

• unnecessary services and ports;
• default accounts;
• debug mode;
• exposed source maps;
• directory listing;
• verbose errors;
• unsafe HTTP methods;
• missing security headers;
• overly permissive CORS;
• weak TLS settings;
• exposed backups and configuration files;
• public cloud storage;
• excessive cloud IAM permissions;
• container privileges;
• management endpoints;
• environment variables containing secrets.

Environment drift matters. A hardened staging environment does not prove that production is configured the same way.

Step 12: Review dependencies and the software supply chain

Create or update a software bill of materials and scan direct and transitive dependencies.

Verify:

• package versions and known vulnerabilities;
• abandoned libraries;
• dependency sources;
• lockfiles;
• registry access;
• package integrity;
• build-system permissions;
• artifact signing;
• secret exposure in CI/CD;
• pull-request protections;
• deployment approvals;
• provenance of containers and artifacts.

A scanner may identify a vulnerable package without determining whether the affected code is reachable. Prioritization should combine severity, exploitability, exposure, and business impact.

Step 13: Test errors, logs, and alerts

Force the application into unexpected states:

• invalid formats;
• unavailable dependencies;
• timeouts;
• duplicate requests;
• partial failures;
• expired credentials;
• full queues;
• interrupted transactions;
• unexpected state transitions.

Check whether the system fails closed, preserves integrity, and avoids exposing stack traces, queries, keys, internal paths, or infrastructure details.

Then verify the defensive response:

• Was the event logged?
• Did the log contain enough context?
• Was sensitive data excluded?
• Did an alert fire?
• Did it reach the correct person?
• Could the team trace the activity across services?
• Did the incident workflow start?

Logging without a tested alert and response path provides limited protection.

Step 14: Validate findings and retest fixes

Automated findings must be reproduced before they are reported as confirmed vulnerabilities. Record:

• affected asset and version;
• prerequisites;
• reproduction steps;
• evidence;
• business impact;
• severity rationale;
• remediation guidance;
• references;
• retest status.

Prioritize using more than a CVSS score. Consider internet exposure, required privileges, exploit complexity, affected data, tenant reach, control bypass, detectability, and operational consequences.

After remediation, rerun the original scenario and relevant regression checks. A fix that blocks one payload may leave the underlying vulnerability intact.

Web application security testing checklist

Authentication and sessions

• Login responses do not reveal whether an account exists.
• Rate limiting and anti-automation controls work.
• MFA is enforced for sensitive actions.
• Password-reset tokens expire and cannot be reused.
• Session IDs rotate after login and privilege changes.
• Logout invalidates the server-side session.
• Cookies use appropriate security attributes.
• Expired and revoked tokens are rejected.
• SSO and OAuth redirect URIs are restricted.
• Secrets and tokens do not appear in URLs or logs.

Authorization

• Every sensitive endpoint performs server-side authorization.
• Users cannot access another user’s objects.
• Normal users cannot call administrative functions.
• Tenant isolation is verified.
• Field-level permissions are enforced.
• Export, bulk, and reporting functions respect access rules.
• Hidden or deprecated endpoints follow current authorization rules.

Input, output, and files

• Input is validated by type, length, range, and format.
• Output is encoded for its destination context.
• Parameterized queries are used.
• Uploaded files are validated by content, extension, size, and storage location.
• User-controlled filenames cannot cause path traversal.
• External URLs are restricted to prevent SSRF.
• Redirect destinations are validated.
• Serialized data is not trusted without verification.

Browser and transport security

• HTTPS is enforced.
• TLS configuration meets current requirements.
• HSTS is enabled where appropriate.
• Content Security Policy is configured and tested.
• Clickjacking protections are present.
• CORS allows only required origins, methods, and headers.
• Sensitive responses are not cached improperly.
• Cookies and browser storage do not expose unnecessary data.

APIs and business logic

• API inventories include old and undocumented versions.
• Object-, function-, and field-level authorization are tested.
• Rate limits apply to high-risk operations.
• Request schemas reject unexpected fields.
• Transaction replay and race conditions are tested.
• Prices, limits, and workflow states are validated on the server.
• Webhook signatures and timestamps are verified.
• Failed multi-step operations preserve data integrity.

Configuration and supply chain

• Debug functionality is disabled.
• Default accounts and credentials are removed.
• Secrets are not committed to source control.
• Dependencies and containers are scanned.
• Build and deployment permissions follow least privilege.
• Artifacts are verified before deployment.
• Cloud storage and administrative services are not publicly exposed.
• Production configuration matches the tested baseline.

Monitoring and recovery

• Authentication and authorization failures are logged.
• Suspicious administrative actions generate alerts.
• Logs do not contain credentials or sensitive personal data.
• Alerts reach an accountable person or system.
• Incident response procedures have been tested.
• Backups are protected and restoration has been verified.
• The system fails safely when dependencies are unavailable.

Web application security testing tools

Tools accelerate discovery and improve repeatability, but their findings require validation.

Burp Suite

Burp Suite is widely used for manual and automated web application testing. Its proxy lets testers inspect and change browser traffic, while tools such as Repeater, Intruder, Sequencer, and Scanner support deeper investigation.

The strongest results come from using Burp to test application-specific hypotheses rather than running the scanner and exporting everything it reports.

OWASP ZAP

OWASP ZAP is suitable for local testing and CI/CD automation. It can proxy traffic, crawl applications, perform passive analysis, and run active scans.

Use passive or baseline scans more frequently. Reserve active scanning for environments where payloads and traffic volume are explicitly permitted.

SAST and dependency tools

Semgrep and CodeQL can provide early code-level feedback. Snyk, Trivy, and similar tools help teams inventory and assess dependencies, containers, and infrastructure configuration.

These tools should block builds only when the finding policy is mature enough to avoid constant false alarms. A pipeline that teams routinely bypass is not a meaningful security control.

Common web application security testing mistakes

Treating the OWASP Top 10 as a complete checklist

The Top 10 highlights broad categories. It does not cover every application-specific threat, compliance requirement, or business-logic failure.

Running a scanner without valid authentication

Unauthenticated scans may miss most of the application. Provide accounts for relevant roles and verify that the scanner reaches protected pages and APIs.

Testing only the user interface

Attackers call APIs directly. Test every endpoint independently of the browser workflow.

Reporting unvalidated scanner findings

Raw output wastes developer time and damages trust in the security program. Reproduce the issue and explain its practical impact.

Ignoring authorization

Injection receives attention because scanners can find it. Broken access control often requires role-aware and object-aware manual tests, yet it remains the first category in OWASP Top 10:2025.

Skipping business-logic testing

A technically valid workflow can still permit fraud or abuse. Test sequences, concurrency, limits, state transitions, and economic rules.

Testing too late

A penetration test immediately before release leaves little time for architectural remediation. Combine early threat modeling and code analysis with runtime testing and periodic independent assessment.

Failing to retest

Closing a ticket does not prove the vulnerability is fixed. Verify remediation using the original exploit path and related variants.

Frequently asked questions

What is web application security testing?

Web application security testing evaluates whether a website, API, and supporting components resist unauthorized access, data exposure, malicious input, privilege escalation, workflow abuse, and other attacks. It combines automated tools with manual analysis and controlled exploitation.

What is the difference between security testing and penetration testing?

Security testing is the broader discipline. It includes threat modeling, SAST, DAST, IAST, dependency scanning, configuration review, security-focused functional testing, and monitoring validation. Penetration testing is a specific activity that simulates realistic attacks to demonstrate exploitability and impact.

Is testing against the OWASP Top 10 enough?

No. The OWASP Top 10 provides a useful baseline but does not replace a threat model, API testing, business-logic testing, supply-chain review, or application-specific requirements. OWASP ASVS can provide more detailed verification criteria.

How often should a web application be security tested?

Automated SAST, dependency, secret, and selected DAST checks can run continuously or with each relevant change. Manual security testing should be performed for high-risk features and architectural changes. Independent penetration testing is commonly scheduled annually and after major changes, although regulatory or contractual requirements may demand a different cadence.

Can web application security testing be automated?

Many checks can be automated, including code patterns, dependency vulnerabilities, secrets, configuration problems, and common runtime weaknesses. Automation is less effective at finding business-logic abuse, complex authorization failures, chained vulnerabilities, and application-specific design problems.

Should security testing be performed in production?

Limited testing may be appropriate in production when it is explicitly authorized, carefully controlled, monitored, and designed to avoid customer or data impact. Destructive techniques should be performed in an isolated environment that accurately represents production.

Build security testing into delivery

Web application security testing works best as a layered process: threat modeling before implementation, SAST and dependency checks during development, DAST and IAST against deployed builds, targeted manual testing for high-risk features, and periodic penetration testing by an independent team.

The important outcome is not the number of scanner findings. It is evidence that critical data, identities, workflows, and trust boundaries remain protected under realistic attack conditions.

For broader coverage across application code, APIs, dependencies, configuration, and delivery pipelines, explore DeviQA’s security testing services.

About the author

Dmitry Reznik

Chief Technology Officer

Dmitry Reznik is the Chief Technology Officer and co-founder at DeviQA, bringing deep technical expertise across software architecture, implementation, and long-term system operation.