Web Application Security: Best Practices and Testing Guide

Web application security is the practice of protecting websites, web apps and the APIs behind them from attacks that abuse their code, configuration, identity flows and third-party components. It combines secure design, controls built into the application and repeated testing.

The 2026 breach data shows why it matters: attackers still log in with stolen passwords or exploit unpatched web software. This guide covers the threat picture, the core controls, the testing toolbox, OWASP ASVS 5.0 levels and a checklist you can work through.

What Is Web Application Security?

Web application security covers everything that decides whether a request to your application can do something it should not. That includes the browser (what scripts may run and where cookies go), the edge (TLS, rate limits, a web application firewall), identity (login, sessions, tokens), the application logic itself (authorization, input handling), the data and secrets it touches, and the open-source and third-party code it is built from.

Three points define the discipline in practice:

• It is mostly an application problem, not a perimeter problem. A firewall cannot tell that user A should not read user B's invoice. Only the application knows who owns the object, so the check has to live in the application.
• It spans the whole lifecycle. Flaws are cheapest to prevent in design and code, but they are only proven absent by testing the running system. A secure SDLC puts both in the same process.
• It is measured against a standard, not a feeling. The OWASP Top 10 tells you what goes wrong most often; the OWASP Application Security Verification Standard (ASVS) tells you what "secure enough" looks like for your risk level. Both are covered below.

Web application security vs application security vs API security

The terms overlap, and teams use them loosely. This is how they relate in practice:

Modern web apps are mostly APIs with a browser on top, so in practice a web application security program must cover its APIs. Our API penetration testing guide explains the API-specific test areas.

The 2026 Threat Landscape for Web Applications

The best public evidence on how web applications are actually breached is the Verizon 2026 Data Breach Investigations Report (DBIR). Its dataset covers October 2024 through November 2025 and includes 22,624 confirmed breaches. Two of its findings matter most for web teams.

Basic Web Application Attacks: stolen credentials first

The DBIR's Basic Web Application Attacks pattern covers attacks that go straight at a web application and then stop: log in with stolen credentials, or exploit a known flaw, and take the data. According to the Verizon 2026 Data Breach Investigations Report:

• The pattern accounted for 3,217 incidents, 2,281 of them with confirmed data disclosure. Against the 22,624 breaches in the dataset, that is about one breach in ten.
• Threat actors were External (100%). Motives were Financial (74%), Espionage (23%) and Ideology (3%).
• Data compromised: Credentials (52%), Internal (48%), Other (33%) and Secrets (15%).
• Use of stolen creds remained the top action. The report also saw a rise in Exploit vuln from large cases of unpatched software, the debut of Password dumper, and Brute force close behind.

Verizon describes the pattern as closer to "oh, they left the door open" than to a sophisticated heist. That is useful framing: most of these breaches need no novel technique, only a missing control.

Exploitation of web-facing software is rising

Across all breaches, the Verizon 2026 Data Breach Investigations Report found that exploitation of vulnerabilities is now the most common initial access vector, at 31%, while credential abuse fell to 13%. Patching is not keeping up: only 26% of critical vulnerabilities (those in CISA's Known Exploited Vulnerabilities catalog) were fully remediated in 2025, down from 38%, and the median time to full resolution rose to 43 days from 32. Breaches with third-party involvement reached 48% of the total.

More complex web exploitation, where attackers go on to deploy ransomware or move through the network, is counted in the DBIR's System Intrusion pattern rather than Basic Web Application Attacks. So the one-in-ten figure understates how often a web application is the entry point.

Real examples from the CISA KEV catalog

These publicly documented cases show the three most common root causes in web software: injection, unpatched internet-facing products and vulnerable components.

The details are in the NVD records for CVE-2023-34362, CVE-2025-61882 and CVE-2025-55182, and in the CISA Known Exploited Vulnerabilities catalog. The Verizon report notes that the group behind the 2023 MOVEit exploitation turned to the Oracle E-Business Suite zero-day in late summer 2025, compromising more than 100 organizations; we covered the Oracle CVE-2025-61882 patch when it was released.

What goes wrong most often: the OWASP Top 10

The OWASP Top 10:2025 ranks the most critical web application risk categories: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions. Broken Access Control stays at number one; OWASP reports that 100% of the applications tested had some form of it.

Each category, with examples and how testers check it, is explained in our OWASP Top 10 2025 guide. The controls below map to those categories.

Core Web Application Security Controls

The controls that stop the attacks above fall into nine groups. Each subsection gives the control, why it matters and the ASVS 5.0 requirement you can use to verify it.

Authentication: assume passwords are already stolen

Stolen credentials are the top action in Basic Web Application Attacks, so authentication is where most teams get the biggest risk reduction for the least effort.

• Offer and enforce multi-factor authentication, especially for administrators and anyone who can reach sensitive data. Prefer phishing-resistant methods; passkeys remove the reusable password entirely.
• Follow current NIST password rules. NIST SP 800-63B-4 (July 2025) requires a minimum of 15 characters when a password is the only factor, and at least 8 when it is used only as part of multi-factor authentication. It says verifiers shall not impose composition rules or require periodic password changes, and must check new passwords against a blocklist of common, expected or compromised values.
• Defend the login form itself. ASVS 5.0 requirement 6.3.1 asks for controls against credential stuffing and password brute force. In practice that means rate limits per account and per source, breached-password checks and alerting on spikes of failed logins. Our credential stuffing statistics show the scale of the problem.
• Treat password reset, MFA enrollment and email change as authentication flows. Attackers target them because they are often weaker than the login page.

Authorization: deny by default, check every object

Broken access control is the most common web flaw class, and scanners struggle to find it because every exploiting request looks legitimate.

• Enforce authorization on the server. ASVS 8.3.1 requires authorization rules at a trusted service layer, not in client-side JavaScript that the user controls.
• Check function-level and object-level access. ASVS 8.2.1 restricts functions to consumers with explicit permissions. Object-level checks stop insecure direct object references (IDOR), where changing an ID in a request returns another user's data.
• Scope every query to the caller. Take the user and tenant from the session, never from the request body.

# Illustrative pattern: scope the lookup to the caller (lab example, not production code)
def get_invoice(session, invoice_id):
    invoice = db.invoices.find_one({
        "id": invoice_id,
        "tenant_id": session.tenant_id,   # from the server-side session
        "owner_id": session.user_id,
    })
    if invoice is None:
        raise NotFound()                  # same response whether it exists or not
    return invoice

Input and output handling: validate, parameterize, encode

Injection flaws such as the MOVEit SQL injection come from mixing untrusted data with code or queries. Three habits remove most of them:

1. Validate input against what the business expects. ASVS 2.2.1 calls for positive validation against an allowlist of values, patterns and ranges, or against an expected structure.
2. Keep data out of the query language. Use parameterized queries or a safe ORM API, never string concatenation.
3. Encode output for its context. ASVS 1.2.1 requires output encoding relevant to the context: HTML element, attribute, CSS or HTTP header. Context-aware encoding, plus a framework that encodes by default, is the main defense against cross-site scripting (XSS).

# Illustrative: a parameterized query keeps user input as data, not SQL
cursor.execute(
    "SELECT id, name FROM customers WHERE email = %s",
    (email_from_request,),
)

Two related risks deserve their own controls. When your server fetches URLs on a user's behalf, restrict destinations with an allowlist and block internal and cloud metadata addresses to prevent server-side request forgery (SSRF). And never deserialize untrusted data into objects; CVE-2025-55182 shows how a framework-level deserialization flaw becomes pre-authentication remote code execution.

Session management: short-lived, server-verified, well-scoped cookies

Once a user logs in, the session token is as good as their password. ASVS 5.0 sets clear baselines:

• Verify sessions on a trusted backend (ASVS 7.2.1) and issue a new session token on every authentication, including re-authentication, ending the old one (ASVS 7.2.4). This prevents session fixation.
• Lock down cookies. ASVS 3.3.1 requires the Secure attribute and the __Host- or __Secure- name prefix. Add HttpOnly so scripts cannot read the token and SameSite to limit cross-site sending.
• Expire and revoke. Use idle and absolute timeouts, and make logout and password change invalidate sessions on the server.

Set-Cookie: __Host-session=<opaque-random-value>; Path=/; Secure; HttpOnly; SameSite=Lax

The __Host- prefix tells the browser to accept the cookie only if it is Secure, has Path=/ and has no Domain attribute, which stops subdomains from overwriting it. The MDN Set-Cookie reference documents each attribute.

SameSite narrows cross-site sending but is not a complete defense against forged requests; our guide to cross-site request forgery (CSRF) covers the token and origin checks that complete it.

Secrets management: nothing sensitive in code or images

Secrets were among the data compromised in 15% of Basic Web Application Attacks breaches in the Verizon 2026 Data Breach Investigations Report. Leaked API keys, database passwords and signing keys turn a small bug into full compromise.

• Use a secrets manager or key vault. ASVS 13.3.1 requires a secrets management solution to create, store, control access to and destroy backend secrets, and says secrets must not be included in application source code.
• Scan for secrets before they land. Run secret scanning in pre-commit hooks and CI, and on the full repository history.
• Rotate and scope. Give each service its own credentials with least privilege, and rotate on a schedule and immediately after any suspected leak.

The OWASP Secrets Management Cheat Sheet covers rotation and lifecycle in detail.

Dependencies and the software supply chain

Most of a modern web application is code your team did not write. OWASP elevated this risk to A03:2025 Software Supply Chain Failures, noting that when tested it has the highest average incidence rate of any category, at 5.19%.

• Keep an inventory. Generate a software bill of materials (SBOM) for every build so you can answer "are we affected?" within minutes of a new advisory.
• Run software composition analysis (SCA) in CI and block builds on known-exploited or critical vulnerabilities in reachable code.
• Set and meet patch deadlines. ASVS 15.2.1 asks you to verify that the application only contains components that have not breached the documented update and remediation time frames. Given the DBIR's 43-day median to fully fix KEV vulnerabilities, a written deadline is a meaningful control.
• Pin and verify. Lock dependency versions, verify package integrity and review new transitive dependencies.

Our guide to supply chain attacks covers build-system and vendor compromise in more depth.

Security headers and Content Security Policy

HTTP response headers tell the browser how to treat your content. They are cheap to deploy and limit the damage when another control fails. ASVS 5.0 section 3.4 sets the baseline:

A nonce-based policy is the most practical way to meet the CSP requirement in a modern app:

Content-Security-Policy: default-src 'self'; script-src 'nonce-<random-per-response>' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Roll out CSP in report-only mode first, fix what it reports, then enforce it. The OWASP Content Security Policy Cheat Sheet and the MDN CSP guide explain each directive. If you run payment pages, our PCI DSS 6.4.3 and 11.6.1 guide shows how script inventories and header monitoring are now required there.

Logging, alerting and error handling

You cannot respond to what you do not record, and logs nobody watches do not help. The 2025 OWASP list calls this category Security Logging and Alerting Failures (it was Security Logging and Monitoring Failures in 2021), which puts the emphasis on alerting.

• Log security events. ASVS 16.3.1 asks that all authentication operations be logged, successful and failed. Also log authorization failures, admin actions, input validation failures and changes to MFA or recovery settings.
• Alert on patterns that match real attacks: bursts of failed logins across many accounts (credential stuffing), many 403 responses to one object range (IDOR probing) and logins from new locations followed by data exports.
• Keep logs safe. Do not log passwords, tokens or full payment data, and protect logs from tampering.
• Fail closed and fail quietly. The new A10:2025 category, Mishandling of Exceptional Conditions, covers errors that leave an app in an insecure state or leak stack traces. Return generic error messages and make sure an exception during an authorization check denies the request.

Edge controls and web application firewalls

A web application firewall (WAF) filters HTTP traffic against rules for known attack patterns; managed cloud WAFs and the open-source ModSecurity engine with the OWASP Core Rule Set are common examples. Rate limiting and bot management sit at the same layer.

These controls are valuable for blocking commodity attacks and buying time while you patch. They are not a substitute for fixing the application: a WAF cannot see that a valid-looking request reads another tenant's data, and it cannot repair broken session handling. Treat edge controls as a layer, and keep them out of your definition of "fixed."

Controls at a glance

The Web Application Security Testing Toolbox

No single test proves an application is secure. Each method sees the application from a different angle, at a different point in the lifecycle, and each has blind spots. The practical answer is a layered mix: automated checks on every change, and human testing where logic and authorization matter.

For a deeper comparison of the automated tools, including where RASP fits, see our guide to SAST vs DAST vs IAST vs RASP. For the human side, our comparison of penetration testing vs bug bounty explains when each fits, and manual vs automated penetration testing covers why tool-only "pentests" miss logic flaws.

Which test catches which flaw

This matrix is a planning aid, not a guarantee: results depend on configuration, scope and tester skill.

The pattern is clear: automation covers the "known pattern in a known place" flaws well, while authorization and logic flaws, the ones behind Broken Access Control, still need people who understand how the application is supposed to behave.

Using a methodology, not a tool list

Whichever mix you choose, anchor testing to a published method so results are repeatable. The OWASP Web Security Testing Guide (WSTG) describes how to test each area, and the ASVS (next section) defines what passing looks like. A good test plan also starts from a threat model, so the riskiest flows get the most attention. For timing, our guide on how often to perform penetration testing covers release-driven and compliance-driven schedules.

OWASP ASVS 5.0: Choosing a Verification Level

The OWASP Top 10 is an awareness list. The OWASP Application Security Verification Standard (ASVS) is the opposite: a detailed list of testable security requirements you can design, build and verify against. It is the closest thing web application security has to a shared definition of "done."

The current version is ASVS 5.0.0, released May 30, 2025, replacing 4.0.3 (October 2021). Version 5.0 has 345 requirements across 17 chapters, from V1 Encoding and Sanitization through V17 WebRTC, including dedicated chapters for self-contained tokens (V9), OAuth and OIDC (V10) and WebRTC (V17). Because identifiers can change between versions, OWASP recommends citing requirements with the version, such as v5.0.0-3.4.3.

The three levels

Each level includes every requirement from the levels below it. Counts are from the 5.0.0 release files:

What changed from ASVS 4.0.3

Two changes matter if your team used the old standard:

• Level 1 is smaller and easier to start with. In 4.0.3, 128 of 278 requirements (46%) were Level 1. In 5.0.0, 70 of 345 (20%) are. OWASP made the change because the large "minimum" level discouraged adoption.
• Levels are no longer defined by black-box testability. Version 4.x picked Level 1 controls partly because an external penetration tester could check them. Version 5.0 sets levels by risk reduction against implementation effort, and OWASP notes that Level 1 is not necessarily testable from outside without access to documentation or code.

The second point has a practical consequence: if you want a test to confirm an ASVS level, give testers documentation, code access or both. A pure black-box test cannot verify every Level 1 requirement.

How to use the ASVS

• Set a target level per application, based on the data it handles and what its users expect, rather than one level for the whole company.
• Fork it. OWASP encourages organizations to drop chapters that do not apply (for example WebRTC or GraphQL if unused) while keeping requirement numbers traceable.
• Use it in procurement. OWASP suggests requiring that purchased or outsourced software meet a named ASVS level, with evidence.
• Scope tests against it. A test plan that lists in-scope ASVS chapters makes results comparable from year to year. Programs such as Google's CASA build their requirements on the ASVS; see our Google CASA guide.

The full standard and machine-readable requirement lists are in the OWASP ASVS GitHub repository.

Where to Start: A Risk-Ordered Plan

If you are building a program from scratch, order the work by what the breach data says attackers use most. This sequence is DeepStrike's editorial recommendation, based on the Verizon 2026 Data Breach Investigations Report patterns and the ASVS levels above:

Web Application Security Best Practices Checklist

Use this checklist as a working baseline. ASVS 5.0 requirement numbers are given where a single requirement maps cleanly.

Identity and sessions

• MFA available to all users and enforced for administrators and sensitive roles
• Passwords follow NIST SP 800-63B-4: 15 characters minimum when single-factor, blocklist check, no forced rotation or composition rules
• Credential stuffing and brute-force controls on login and reset (ASVS 6.3.1)
• Session tokens verified server-side (ASVS 7.2.1) and rotated on every login (ASVS 7.2.4)
• Cookies use Secure, HttpOnly, SameSite and the __Host- prefix (ASVS 3.3.1)
• Logout, password change and MFA reset invalidate active sessions

Authorization

• Authorization enforced at a trusted server layer, never only in the browser (ASVS 8.3.1)
• Every function restricted to explicit permissions (ASVS 8.2.1)
• Every object lookup scoped to the caller's user and tenant
• Automated two-user tests for sensitive endpoints in CI

Input, output and data

• Allowlist validation for business inputs (ASVS 2.2.1)
• Parameterized queries everywhere; no string-built SQL
• Context-aware output encoding (ASVS 1.2.1) and a framework that encodes by default
• Outbound requests restricted to an allowlist; internal and metadata addresses blocked
• No deserialization of untrusted data into objects
• File uploads checked for type and size and stored outside the web root

Secrets and supply chain

• Secrets in a vault, none in source code or images (ASVS 13.3.1)
• Secret scanning in pre-commit, CI and repo history
• SBOM generated for every build; SCA blocks critical and KEV-listed issues
• Written patch deadlines that components never exceed (ASVS 15.2.1)

Browser and transport

• HSTS with max-age of at least one year (ASVS 3.4.1)
• CORS limited to an allowlist of trusted origins (ASVS 3.4.2)
• CSP with object-src 'none', base-uri 'none' and nonces or hashes (ASVS 3.4.3)
• X-Content-Type-Options: nosniff and a Referrer-Policy (ASVS 3.4.4, 3.4.5)

Detection and resilience

• All authentication events logged, success and failure (ASVS 16.3.1)
• Alerts for credential stuffing, access-control probing and unusual exports
• Generic error messages; exceptions fail closed
• WAF and rate limits in front of public endpoints, treated as a layer, not a fix

Testing and governance

• Target ASVS level chosen for each application
• SAST, SCA and secrets scanning on every change; DAST on a schedule
• Threat model for new features that touch money, identity or sensitive data
• Authenticated manual penetration test before major releases and at least yearly, with re-testing of fixes

Frequently Asked Questions

What is web application security in simple terms?

It is the set of practices, controls and tests that stop people from using a website or web app in ways it was not meant to be used: logging in as someone else, reading data they should not see, running their own code or taking the service down. It covers code, configuration, identity, dependencies and the browser.

Why is web application security important?

Web applications are directly reachable from the internet and hold the data attackers want. In the Verizon 2026 Data Breach Investigations Report, the Basic Web Application Attacks pattern alone accounted for 2,281 confirmed breaches, and exploitation of vulnerabilities was the most common initial access vector across all breaches, at 31%.

What are the top 5 web application vulnerabilities?

Using the OWASP Top 10:2025 order, the first five categories are Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures and Injection. Our OWASP Top 10 guide explains each one with examples.

What is an example of a WAF, and is a WAF enough?

Managed cloud WAFs and the open-source ModSecurity engine running the OWASP Core Rule Set are common examples. A WAF is not enough on its own: it filters known attack patterns but cannot understand your authorization rules or business logic, so flaws such as IDOR pass straight through.

Is SonarQube a SAST or DAST tool?

SonarQube is a static analysis tool, so it belongs in the SAST category: it analyzes source code without running the application. DAST tools test the running application over HTTP. Most teams need both, plus SCA for dependencies.

What are the OWASP ASVS levels?

ASVS 5.0 has three levels. Level 1 (70 requirements) covers first-layer defenses for every application, Level 2 (183 more, 253 in total) is the level OWASP says most applications should strive for, and Level 3 (92 more, all 345) is for applications that need the highest assurance.

What is the difference between the OWASP Top 10 and the ASVS?

The Top 10 is an awareness document that ranks the most critical risk categories. The ASVS is a verification standard with specific, testable requirements grouped into levels. Use the Top 10 to understand what goes wrong and the ASVS to define and test what "secure enough" means for your application.

How often should a web application be security tested?

Run SAST, SCA and secrets scanning on every change and DAST on a regular schedule. Add an authenticated manual penetration test before major releases and at least once a year, and re-test after fixing significant findings. Compliance frameworks and customer contracts may set stricter schedules.

Next Step: Verify Your Controls the Way an Attacker Would

Web application security comes down to a short list done well: strong authentication, server-side authorization on every object, safe handling of input and output, managed secrets, patched dependencies, sensible headers and logs that someone watches. Automated tools keep those controls from slipping on each release. Proving that they hold together, across roles, tenants and real business flows, still takes a human tester.

DeepStrike's web application penetration testing uses rigorous manual testing based on how your application is supposed to work, with security checks from multiple users' perspectives and only vulnerabilities validated through exploitation. You get a detailed report with fix recommendations, a technical presentation for your engineers, a shared Slack channel during the engagement and re-testing to confirm fixes hold. To scope a test for your application, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• Verizon 2026 Data Breach Investigations Report
• OWASP Application Security Verification Standard 5.0.0 (May 30, 2025)
• OWASP ASVS 5.0.0 source files on GitHub
• OWASP Top 10:2025
• OWASP Top 10:2025 A03 Software Supply Chain Failures
• OWASP Web Security Testing Guide
• OWASP Secrets Management Cheat Sheet
• OWASP Content Security Policy Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Query Parameterization Cheat Sheet
• OWASP Logging Cheat Sheet
• NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management (July 2025)
• NIST SP 800-218: Secure Software Development Framework (February 2022)
• CISA Known Exploited Vulnerabilities Catalog
• NVD: CVE-2023-34362
• NVD: CVE-2025-61882
• NVD: CVE-2025-55182
• MDN: Content Security Policy (CSP)
• MDN: Set-Cookie header