Why Functional Testing Isn't Enough for Web Application Security

A web application can pass every functional test and still contain serious security vulnerabilities.

The login page works. The contact form submits successfully. The API returns the expected response. The deployment pipeline is green.

Everything looks fine.

But what happens when someone changes a request parameter, accesses another user's resource, or submits input the application wasn't designed to handle?

These scenarios highlight an important distinction between functional testing and security testing.

Functional testing verifies whether an application behaves as expected. Web application vulnerability assessment examines how the application behaves when its security assumptions are challenged.

Let's explore why both are necessary and how development teams can approach vulnerability assessment more effectively.

1. Functional correctness does not guarantee security

Consider a simple API endpoint:

GET /api/orders/1042
Authorization: Bearer <access_token>

A functional test might verify that an authenticated user can retrieve order 1042.

If the API returns the expected data, the test passes.

But what if the user changes the request to:

GET /api/orders/1043
Authorization: Bearer <access_token>

If order 1043 belongs to another customer, the application must enforce object-level authorization.

Otherwise, a user may access data they should not be able to see.

This is an example of a broken object-level authorization vulnerability.

The application may work perfectly from a functional perspective while failing to protect sensitive information.

This is why security testing needs to examine more than expected user behavior.

2. What does a web application vulnerability assessment cover?

A vulnerability assessment identifies and evaluates security weaknesses in an application.

The exact scope depends on the architecture, business requirements, and sensitivity of the data involved.

Common assessment areas include:

Area	Typical security concerns
Authentication	Weak login protection, account recovery issues
Authorization	Unauthorized access to functions or data
Input handling	SQL injection, cross-site scripting
Session management	Insecure cookies, session handling weaknesses
File uploads	Unsafe file processing and validation
APIs	Missing authorization, excessive data exposure
Configuration	Exposed debug features, insecure settings

These categories are not independent.

For example, a weakness in session management may interact with an authorization flaw, increasing the potential impact.

A useful assessment therefore considers both individual vulnerabilities and how application components interact.

3. Automated scanning is useful, but it has limits

Automated vulnerability scanners can help identify common security weaknesses.

They are particularly useful for repeatable checks, broad endpoint coverage, and detecting known patterns.

For example, a scanner may flag missing security headers, outdated components, or certain input validation weaknesses.

However, automated scanning cannot reliably understand every application's business rules.

Consider an expense approval system.

An employee can submit a reimbursement request, and a manager can approve it.

A security issue may exist if employees can approve their own requests by manipulating an API call.

Detecting this requires understanding the intended business workflow and authorization rules.

An automated scanner may not have enough context to identify the problem.

This is where manual security testing becomes valuable.

A balanced assessment often combines automated checks with targeted manual verification.

4. API security deserves particular attention

Modern web applications frequently depend on APIs.

A single frontend may communicate with several backend services, including authentication systems, payment providers, and internal business applications.

As a result, API security has become a central part of application security.

Consider an endpoint:

PATCH /api/users/204/profile
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "displayName": "Example User"
}

The backend should verify that the authenticated user is authorized to modify the requested profile.

It should also validate the accepted fields and prevent unauthorized changes to protected properties.

Important API security considerations include:

• Object-level and function-level authorization
• Input validation
• Authentication and token handling
• Rate limiting where appropriate
• Sensitive data exposure
• Secure configuration
• Logging and monitoring

The OWASP API Security Top 10 provides a useful framework for identifying common API security risks.

However, a checklist alone is not sufficient. Testing must reflect the application's actual data flows and permission model.

5. When should vulnerability assessments happen?

A common mistake is treating security testing as a one-time activity immediately before launch.

While pre-release testing is important, vulnerabilities can also be introduced after deployment.

For example, a team may add a new API endpoint, modify user permissions, or integrate an external service.

Each change can affect the application's security posture.

There are several useful assessment points throughout the development lifecycle.

Before production release

Assess critical application functions, authentication, authorization, and data handling before exposing the system to real users.

After significant changes

Reassess affected components when introducing new functionality, changing access controls, or modifying integrations.

During ongoing operations

Schedule assessments based on the application's risk level, exposure, and rate of change.

After major vulnerability disclosures

When a serious vulnerability is reported in a framework, library, or runtime used by the application, investigate exposure and apply the relevant remediation.

The goal is to make security verification part of the application lifecycle rather than an isolated event.

6. Integrating security testing into CI/CD

Not every security test needs to be performed manually.

Development teams can automate several security checks within their pipelines.

A simplified workflow might look like this:

Code Commit
    |
    v
Static Analysis / SAST
    |
    v
Dependency Scanning
    |
    v
Build & Deploy to Test Environment
    |
    v
Automated DAST
    |
    v
Manual Security Review (Risk-Based)
    |
    v
Production Release

Static Application Security Testing (SAST) examines source code or related artifacts for potential security issues.

Dynamic Application Security Testing (DAST) examines a running application.

Dependency scanning helps identify known vulnerabilities in third-party components.

These approaches complement one another, but none guarantees complete coverage.

For applications with complex business logic or sensitive workflows, manual assessment remains important.

7. Finding vulnerabilities is only the beginning

A vulnerability assessment produces findings, but those findings do not automatically make an application more secure.

The next step is remediation.

A practical process usually includes:

1. Validation: Confirm whether a finding represents a real security issue.
2. Prioritization: Evaluate severity, exploitability, exposure, and business impact.
3. Remediation: Fix the underlying weakness.
4. Retesting: Verify that the issue has been resolved.
5. Regression testing: Confirm that the fix has not broken expected functionality.

Severity scores can support prioritization, but they should not be the only factor.

A moderate-severity issue affecting a critical business workflow may require urgent attention.

Similarly, an issue in an internet-facing system may deserve different treatment from the same issue in a tightly restricted environment.

8. Choosing a vulnerability assessment approach

The appropriate assessment depends on the application.

A public marketing website, a customer portal, and a financial transaction platform have different threat models.

Before selecting an assessment method, engineering teams should clarify:

• Which applications, APIs, and environments are in scope?
• What sensitive data does the system handle?
• Which user roles and permission levels exist?
• What testing methods are permitted?
• Who will implement and verify fixes?
• How will findings be prioritized and documented?

These questions help ensure the assessment produces actionable results rather than just a long list of scanner alerts.

For teams looking for a more detailed overview, SotaTek Japan has published a Japanese-language guide covering web application vulnerability assessment, common testing categories, assessment methods, costs, and implementation steps.

Further reading: Web Application Vulnerability Assessment: Testing Areas, Costs, and Process — SotaTek Japan

The guide also discusses how assessment findings can be connected to remediation and follow-up verification.

Final thoughts

A web application that functions correctly is not necessarily secure.

Functional tests verify expected behavior, while vulnerability assessments examine potential weaknesses in authentication, authorization, input handling, APIs, and other security-sensitive components.

Automated scanners can provide valuable coverage, but manual testing is often needed to evaluate business logic and complex access-control scenarios.

Most importantly, security assessment should not end with a report.

The real value comes from identifying risks, fixing the underlying issues, and verifying that the application is safer afterward.

---

Suggested tags: #security #webdev #testing #devops