Web Application Security Testing: A Complete Guide

Web application security testing is the process of evaluating a website or web application for security weaknesses that attackers could exploit. It covers three main approaches: automated scanning (also called dynamic application security testing, or DAST), which probes a running application for known vulnerability patterns; manual penetration testing, where a skilled human attacks the application the way a real adversary would; and static analysis (SAST), which reviews source code before it ships. The goal is to find flaws such as broken access control, injection, and security misconfiguration before attackers do, then fix them and verify the fixes. Most organizations combine continuous automated scanning with periodic manual testing, because each approach catches problems the other misses, and frameworks like SOC 2 and ISO 27001 expect evidence of both.

That is the short answer. The longer answer is where most teams get into trouble, because "we test our application" can mean anything from a free scanner run once a year to a structured program with defined scope, cadence, and audit-ready evidence. This guide walks through what each testing type actually does, what it finds and misses, how often to test, and how to build a program that holds up against both attackers and auditors.

What Are the Main Types of Web Application Security Testing?

Testing methods are usually grouped by how they interact with the application. Three types cover the vast majority of real-world programs.

Automated Scanning (DAST)

Dynamic application security testing runs against a live, deployed application. A scanner crawls the app, sends crafted requests, and analyzes the responses for signs of trouble: error messages that leak stack traces, reflected input that signals cross-site scripting, missing security headers, outdated server software, expired or misconfigured TLS certificates.

Because DAST tests the running system, it sees your application the way an attacker sees it, including the web server, the TLS layer, and everything sitting in front of your code. Quality varies widely between tools, though. Some platforms quietly serve cached results instead of probing your infrastructure fresh each time. We built our automated scanning service, OnScanner, around live, non-cached scanning for exactly this reason: a report is only useful if it describes your application as it exists right now, not as it existed last week.

Manual Penetration Testing

A manual penetration testing engagement puts a human tester against your application within a defined scope and time window. The tester does what no scanner can: understands what the application is for, chains individually minor issues into serious compromises, and abuses business logic. Can a user edit another user's data by changing an ID in the URL? Can a free-tier account reach paid features by replaying a request? Can the checkout flow be manipulated into a negative total? These are judgment calls, not signatures, and they require a person.

Static Analysis (SAST) and Code Review

Static application security testing analyzes source code without running it. It flags injection-prone query construction, hardcoded credentials, unsafe deserialization, and weak cryptographic choices early, often directly in the development pipeline before the code ever ships. Its blind spot is everything that only exists at runtime: server configuration, deployed dependencies, access control as actually enforced. SAST also tends to produce noise, so it works best as a developer-facing guardrail that complements the other two types rather than replacing them.

What Does Each Testing Type Find and Miss?

No single method covers the whole risk surface. Knowing the gaps is the difference between a testing program and a false sense of security.

Automated scanning is strongest at breadth and repetition. It reliably catches security misconfiguration, missing headers, vulnerable and outdated components, exposed admin panels and debug endpoints, certificate problems, and many textbook instances of injection and cross-site scripting. It can run every day across every property you own, which no human team can.

Automated scanning is structurally weak at context. Broken access control, the top category in the OWASP Top 10, is the clearest example. A scanner cannot know that a given record belongs to a different customer and should never be visible to this session. Business logic flaws, multi-step attack chains, and authorization decisions all require understanding intent, and intent does not show up in an HTTP response.

Manual testing is strongest exactly where scanners fail. Access control violations, privilege escalation, logic abuse, authentication weaknesses, and chained exploits are the classic findings of a good penetration test. Its limits are practical rather than technical: an engagement is a point-in-time exercise with a fixed budget of hours, so it cannot watch your application continuously or re-check every release.

SAST is strongest early and shallowest late. It finds dangerous code patterns before deployment but says nothing about how the system behaves once it is configured, integrated, and exposed to the internet.

For a deeper side-by-side comparison of the two dynamic approaches, see our breakdown of automated scanning versus manual penetration testing.

How Do You Choose the Right Testing Approach?

The honest answer is that mature teams do not choose one. They sequence them. The real question is what to do first, and that depends on where you are:

• You have never tested anything. Start with automated scanning to establish a baseline and clear the obvious findings, then schedule a manual test once the noise is gone so the tester's hours go toward deep issues instead of missing headers.
• You are about to launch and will handle sensitive data. Book a manual penetration test before go-live. First impressions with customer data are hard to repair.
• You run a live product and ship frequently. Continuous scanning between releases, plus a scheduled manual test, is the standard pattern.
• You have a compliance deadline. Work backwards from what your auditor expects, and remember that findings need remediation time before the audit window closes.

How Often Should You Test a Web Application?

Cadence depends on the method, because each one answers a different question.

• Automated scanning: continuously, or on a tight recurring schedule. Every deploy can introduce a new exposure, and scanning is cheap enough to run constantly. A scan from last quarter describes an application that no longer exists.
• Manual penetration testing: at least annually, and after significant changes. A new authentication system, a major feature, a re-architecture, or an acquisition all justify an out-of-cycle test. Standards bodies agree on this rhythm: PCI DSS, for example, requires penetration testing annually and after significant changes, and SOC 2 auditors commonly expect an annual test as evidence.
• Retesting: after every remediation. A finding is not closed because a ticket was marked done. Verify the fix, and keep the verification record.

What Does a Security Testing Program Look Like for a SaaS Company?

For a typical SaaS business, a defensible program is layered, and each layer covers a gap in the others:

• Continuous automated scanning of production and staging, with alerts routed to the engineering team rather than a mailbox nobody reads.
• An annual manual penetration test with a written scope covering the application, its APIs, and its authentication and multi-tenancy boundaries.
• Out-of-cycle testing when something significant changes: new auth flows, new data categories, major integrations.
• SAST or structured code review in the development pipeline for high-risk changes, so entire bug classes are caught before deployment.
• A remediation workflow that assigns every finding a severity, an owner, and a deadline, and tracks it to verified closure.
• Evidence retention: scan reports, penetration test reports, and remediation records, kept where an auditor can reach them.

The last two items are where most programs quietly fail. Finding vulnerabilities is the easy half. If you are planning your first engagement and want to understand scoping, methodology, and what a real report should contain, our manual penetration testing guide covers the full lifecycle.

What Vulnerabilities Does Web Application Security Testing Find?

The most widely used reference for web application risk is the OWASP Top 10. The 2021 edition lists:

• A01: Broken Access Control
• A02: Cryptographic Failures
• A03: Injection (which now includes cross-site scripting)
• A04: Insecure Design
• A05: Security Misconfiguration
• A06: Vulnerable and Outdated Components
• A07: Identification and Authentication Failures
• A08: Software and Data Integrity Failures
• A09: Security Logging and Monitoring Failures
• A10: Server-Side Request Forgery (SSRF)

The ordering tells a story. Broken Access Control moved to the top spot in 2021, and it is precisely the category automated tools struggle with most, which is the strongest single argument for keeping humans in your testing program. Injection, the long-time number one, dropped to third as frameworks made it harder to write by accident. The list keeps evolving; our analysis of the OWASP Top 10 in 2026 covers what has changed since and what it means for your applications.

How Does Security Testing Feed SOC 2 and ISO 27001 Compliance?

Security testing and compliance are usually treated as separate projects. They should not be, because testing output is compliance evidence.

For SOC 2, auditors evaluating the Security criteria will ask how you identify and remediate vulnerabilities. Recurring scan reports, an annual penetration test report, and a remediation log with verified closure dates answer that question directly. For ISO 27001, the Annex A controls on technical vulnerability management expect an organized process for finding and handling weaknesses, and your testing program is that process, documented. Under GDPR, Article 32 explicitly calls for regularly testing, assessing, and evaluating the effectiveness of your technical measures.

Two practical warnings. First, a penetration test report full of open critical findings is not helpful evidence; auditors care about what happened after the test. Second, timing matters: schedule testing early enough in your audit cycle to remediate and retest before the review. If you are mapping testing activity to specific framework requirements, our compliance consulting team helps companies prepare for SOC 2, ISO 27001, and GDPR by building exactly that mapping, along with the policies auditors expect around it.

Where Should You Start?

If you have never tested your application, start this week with an automated scan to get a baseline. If you already scan, look at your findings honestly: if every report is clean, the more likely explanation is that your tool cannot see the problems, not that you have none. Add a manual penetration test and find out what a human can do to your application.

And whichever route you take, close the loop. Fix what you find, verify the fix, and keep the records. That is the difference between running scans and running a security testing program.

Frequently asked questions

What is the difference between DAST and SAST?

DAST (dynamic application security testing) probes a live, deployed application from the outside, so it sees the web server, the TLS layer, and the configuration the way an attacker does. SAST (static application security testing) analyzes source code before it runs, catching injection-prone queries, hardcoded credentials, and weak cryptography early in the pipeline. SAST is blind to runtime behavior, which is why the two complement rather than replace each other.

Can automated scanning replace a penetration test?

No. Scanners are strong at breadth and repetition, reliably catching misconfiguration, missing headers, and outdated components. They are structurally weak at context: broken access control, business logic abuse, and multi-step attack chains require a human who understands what the application is for. Frameworks like SOC 2 and ISO 27001 expect evidence of both approaches, which is why mature programs combine them.

How often should you run a penetration test?

At least annually, and after significant changes such as a new authentication system, a major feature, a re-architecture, or an acquisition. PCI DSS requires penetration testing annually and after significant changes, and SOC 2 auditors commonly expect an annual test as evidence. Automated scanning should keep running continuously between manual engagements, and every remediation should be followed by a verified retest.

Does security testing count as compliance evidence?

Yes. SOC 2 auditors ask how you identify and remediate vulnerabilities, and recurring scan reports, an annual penetration test report, and a remediation log with verified closure dates answer that directly. ISO 27001 Annex A expects an organized vulnerability management process, and GDPR Article 32 calls for regularly testing your technical measures. Auditors care most about what happened after the test, so keep the remediation and retest records.