Security testing and application security testing: methods, what each finds, and a minimum plan

Security testing checks whether software and its infrastructure resist attack. Application security testing is any method that looks for security flaws in an application before an attacker finds them. The methods differ in what they read (code, dependencies or a running app), who runs them (a tool or a person) and which flaws they can see. No single method covers all of it.

What is application security testing?#

Security testing looks for ways a person could misuse a system: read data they should not see, change data they should not change, or stop the service. It reports weaknesses with enough evidence for a team to fix them. Application security testing covers every such check on software you build or run. It includes tools that read source code, tools that probe a running app, and people who test by hand.

The methods fall into two groups. Automated checks run often and cheaply, and they find known patterns. Manual testing is slower and finds flaws that depend on how your app is meant to behave.

NIST's Secure Software Development Framework (SP 800-218, version 1.1, final since February 2022) treats testing as one part of building software, next to design, review and fixing. It gives "a core set of high-level secure software development practices" that you can fit into any development process (NIST CSRC). It does not pick one tool for you.

NIST SP 800-115, "Technical Guide to Information Security Testing and Assessment", is the long-standing government reference for technical testing. NIST published it in September 2008 and still lists it as final, so read it as a method guide and not as a current requirement (NIST CSRC). The OWASP Application Security Verification Standard (ASVS) lists what a secure application should do. Version 5.0.0 was published on 30 May 2025 (OWASP ASVS).

This guide uses "web application security testing" for the same work when the target is a web app and its API.

How does security testing differ from functional testing?#

Functional testing checks that a feature does what the specification says. Security testing checks what the feature does when someone uses it in a way the specification did not plan.

A functional test for a note-sharing app asks: "Can I share a note with a colleague?" A security test asks: "Can I read a note that nobody shared with me by changing its ID in the request?" The second test needs a second account and a request edit, and a normal test plan has neither.

QA teams know the flows, roles and edge cases, so they can run checks and tools. Finding broken access control and logic flaws takes security skills, such as testing with two accounts and reading client code. Many teams pair QA with a security tester.

The methods in one table#

Each method answers a different question. The table gives the OWASP DevSecOps Guideline's wording where it defines the term, and our plain summary of what it can and cannot see.

The "usually finds" and "usually misses" columns are our summary of how the methods work. OWASP's DAST page names input and output validation, authentication issues and server configuration mistakes as DAST's strong areas, and its pages do not list weaknesses. OWASP's tool page notes that some tools cover several types, such as SAST, DAST and software composition analysis, so one product name can appear under more than one row (OWASP Vulnerability Scanning Tools).

For the human side, read what is penetration testing and types of penetration testing. The pentest and red team split is in red team vs penetration testing.

Which method finds which problem?#

Match the method to the flaw class. The OWASP Top 10:2025 lists Broken Access Control as A01 (OWASP). That class depends on who the caller is and which record they ask for, which a tool cannot know without your rules.

For the access control rows, see our guides on IDOR testing and multi-tenant isolation testing. For workflow flaws, see business logic vulnerabilities.

Which question does each method answer?#

Choose the method from the question you need answered. The table also names the method people often confuse it with.

The OWASP DevSecOps Guideline describes DAST as black-box testing that does not need source code. That fits the input-flaw row. It does not fit the cross-customer row, where the test needs knowledge of roles and tenants. The buyer-side comparison of scans and pentests, with provider facts, is on pentestcompare.com.

What is the difference between SAST and DAST?#

SAST reads code and DAST attacks a running app. SAST needs source access and can point to a line. DAST needs only a URL and shows what an outside caller can reach. Pair them because each sees what the other cannot.

Our SAST guide, DAST guide and SAST vs DAST comparison cover setup, noise and where each belongs in a pipeline.

IAST sits between the two. It runs inside the app while tests exercise it, so its coverage is only as good as the tests or the people driving the app.

A minimum program for a small SaaS team#

A small team needs a short list it can keep up. This plan has five steps, ordered by cost and payoff. It is our suggestion, not a standard.

1. Turn on dependency checks (SCA) and secret scanning in the repository. These run on every pull request and need little tuning.
2. Add SAST to the build for your main language. Start with a small rule set and fix or suppress findings so the report stays clean.
3. Run a DAST scan against staging on a schedule. Give it a signed-in user so it reaches pages behind the login.
4. Book a pentest before your first public launch, then after major changes to authentication, billing, roles or tenant handling.
5. Keep a one-page record of what you ran, when, and what you fixed. Customers and auditors ask for this.

Ask the requester which evidence they accept before you pick. A security questionnaire or contract may name a specific method; see security questionnaire pentest questions. Our guide on how often to pentest covers timing.

What security testing should you run before launch?#

Run automated checks continuously and a pentest on the release candidate. Check off each line before you invite customers.

• Inventory: list hosts, domains, APIs, third-party services and user roles.
• Dependencies: run an SCA check and update or accept each known-vulnerable library.
• Secrets: search the repository history for keys and tokens, and rotate any you find.
• Code: run SAST in CI and review the code that handles login, sessions, payments and file uploads.
• Configuration: check headers, cookie flags, TLS, CORS and debug endpoints on the staging site.
• Scan: run a DAST scan with a logged-in test account, and confirm that it reached authenticated pages.
• Access control: test every object endpoint with a second account and with no account.
• Pentest: book a test of the release candidate, with a written scope and test accounts for each role.
• Fix and retest: fix findings, then retest them, and record any accepted risk in writing.
• Monitoring: confirm that failed logins, rate limit hits and server errors reach someone who will see them.

Our guide on how to prepare for a penetration test lists what a tester needs from you: scope, accounts, a staging site and a contact. Test again after changes to login, billing, roles or tenant logic.

Who does the testing: your team, a tool or a provider?#

Developers and QA own the automated checks. A person with security skills should own access control, logic and chained-attack testing. A provider fits when you need independence, a report a customer will read, or skills you do not have.

Web application security testing: what the work covers#

Web application security testing covers the browser-facing app, the APIs behind it, authentication and session handling, and how roles and tenants are separated. The OWASP Web Security Testing Guide is the main open reference for the test cases. As of November 2026, its stable release is v4.2 and version 5.0 is in development (OWASP WSTG).

A pentest of a web app usually works through these areas:

• Sign-up, login, password reset and multi-factor flows (authentication testing checklist).
• Session cookies, tokens and logout.
• Authorization on every route and object, with at least two accounts per role.
• Input handling for injection and cross-site scripting.
• Business workflows such as checkout, invitations and plan changes.
• API routes the front end never calls (API penetration testing).

Our web application penetration testing page lists what we test and what you receive.

Authorization and safe testing#

Test only systems you own or have written permission to test. Active methods (DAST, IAST driven by a tester, pentests) send real requests and can change data or trigger emails and payments.

Before any active test, agree these points in writing:

• The hosts, URLs and APIs in scope, and what is out of scope.
• The environment: staging first, production only with tighter limits.
• Test-owned accounts and records, marked as test data.
• Limits on volume, uploads, password guessing and any paid third-party calls.
• A contact who can stop the test, and a channel for urgent findings.
• No testing of third-party services you do not control. A manager's oral approval is not enough for a third-party host.
• Secure storage for evidence, shared through an agreed channel.

NIST SP 800-115 says legal advisors should always be involved in intrusive tests such as penetration testing (NIST CSRC). Check your contracts and your cloud provider's rules before you test. Our rules of engagement guide gives a checklist.

How do you choose a provider?#

Choose by what evidence the provider shows, not by tool names. Ask for a sample report, and check whether each finding has requests, responses and a read-back that proves the effect. Ask which accounts and roles they test with.

Our pentest approach is described on the methodology page and in the sample report. For a neutral comparison of how scans and pentests differ, read pentest vs vulnerability scan on PentestCompare. PentestCompare is published by Excession Labs and names its other providers from sourced facts.

If you want a scoped test of your app, request a pentest.