Web application security testing: what testers check beyond a scanner

Web application security testing checks whether an application's security controls work as intended. It can include automated checks, code review and penetration testing. This article is about an authorized, expert-led test of a running web application — a website, customer portal or online store — in which testers examine how it signs users in, keeps sessions, enforces permissions and handles data. Website penetration testing is one form of it.

Testers often combine scanners with manual checks. Depending on the tool and its configuration, a scan can flag known vulnerabilities in the components it identifies, missing security headers and weak connection encryption (TLS settings). What a scanner cannot judge on its own is whether a response is right for the person asking. It sees that an order page loads; unless someone has told it which orders belong to whom, it does not know the order is someone else's. NIST's 2008 testing guide notes that application scanners typically have high rates of false alarms (false positives) and also miss real issues, which is why their results need interpretation (NIST SP 800-115, section 4.3).

What web application security testing covers

The areas are well established. OWASP's public Web Security Testing Guide groups them into categories; its current stable version, 4.2, was released in December 2020 (OWASP WSTG). Depending on the agreed scope, a test usually covers:

• Authentication: sign-in, password reset, multi-factor steps and account lockout.
• Sessions: how the application keeps you signed in, and whether a session ends when it should.
• Access control: whether each user reaches only the data and functions their role allows.
• Input handling: whether the application handles unexpected data safely, including attempts to make it treat supplied data as commands or code (injection).
• Business logic: whether the application's own rules hold when steps are skipped, repeated or reordered.
• Configuration and components: server settings, error messages, exposed files and outdated libraries.
• Data handling: which sensitive data is stored, sent or shown, and to whom.

Access control between users and roles

Broken access control is first in the OWASP Top 10:2025, the project's awareness list of web application security risks (OWASP Top 10:2025).

The typical case is simple to describe. A customer signs in to a portal and opens an invoice at an address ending in /invoices/1042. They change the number to 1041 and see another customer's invoice. Nothing looks broken: the page loads normally, and a scanner that was not told who owns which invoice moves on. Two test accounts with separate invoices, and someone who knows which invoice belongs to whom, make this easy to verify. Automated checks can compare access between accounts once they are configured with the expected permissions; a tester sets those expectations and investigates the exceptions.

Testers repeat this across roles. Can a regular user reach an administrator function? Can one client company see another's data on a shared platform? Can a user whose access was removed still act through an old link?

Business logic: testing your own rules

A vulnerability list cannot tell a tester how your application's business rules should work; your team explains the intended limits and the order of the steps. A discount code that should work once. A payment step that must come before shipping. A quantity that should never be negative. A daily limit on transfers.

A tester checks what happens when those rules meet an unexpected sequence: the same request sent twice, a step skipped, a price or an account number changed on the way to the server. For an online store, a flaw like this is a pricing problem as much as a security one.

API security testing: the same application, another door

Modern web and mobile applications talk to their servers through APIs — the interfaces software uses to exchange data — and an API can be called directly, without the screens that normally limit what a user can do. So a test that only follows the visible screens can miss requests the API accepts directly; the server has to enforce permissions even when a request never passes through those screens. The OWASP API Security Top 10 2023 puts broken object level authorization first: the API version of the invoice example (OWASP API Security Top 10 2023).

API testing works best with its own inputs: the API documentation or an OpenAPI description if one exists, test credentials for each type of client, and the list of endpoints (API addresses) in scope. IntruForce offers API security testing as a separate service; it looks at how the API authenticates users and systems, enforces permissions, processes requests and exposes data.

Web application security testing vs a scanner

Both have a place, and they answer different questions. For systems in general, see vulnerability scan vs penetration test.

What a scanner does well

• Known vulnerabilities in the components and versions it can identify.
• Missing security headers, weak TLS settings and exposed default files.
• Repeating the same checks after every release.

What needs a tester

• Access control between users, roles and client companies: deciding what each should see, then checking it.
• Business logic and the order of steps in a process.
• Chains of small issues that add up to a serious one.
• Judging whether a finding — a potential security issue — matters for this particular application.

How to scope a web application test

Agree the targets and obtain written authorization before testing. Record the test window, the permitted actions, any limits on request volume, and a contact who can stop the work; agree as well how test data and evidence will be handled. Then define:

• The application and its parts: the URLs, the APIs behind them and the admin areas.
• Roles and test data: which roles and client companies are represented. Where users should have separate access, provide accounts with records of their own, so testers can compare permissions.
• Environment: a staging copy that mirrors production, or production with agreed limits.
• Key flows: sign-up, payment, approval, export — the steps that carry money or data.
• Third parties: payment gateways and other services you do not own stay out unless their owner allows testing.
• Protective layers: whether a web application firewall stays on, so the test runs through the controls an attacker would meet, or is relaxed for the testers' addresses under a separate authorization, so the application's own behaviour can be examined. Record which configuration applied to which checks, and the limits of each.

If your team wants a list of requirements to test against, OWASP's Application Security Verification Standard (ASVS) is written for that purpose; version 5.0.0 was released on May 30, 2025 (OWASP ASVS).

What you receive

A web application security test by IntruForce assesses the websites, customer portals, online stores, CRM interfaces and other web applications in the agreed scope. You receive confirmed findings with supporting evidence, an explanation of the affected functionality and practical recommendations for development and IT teams. What a good report contains, finding by finding, is covered in what a penetration test report should contain.

To discuss a test, describe the application and what concerns you about it in the request form on the services page. Sending a request does not commit you to purchasing a service, and tests that interact with your systems are agreed separately.